Subject: Re: iSCSI: immediate data

From: [email-masked]
Date: Wed, 9 May 2001 10:12:27 +0300

That is correct. The final bit indicates the end of unsolicited  data.
If all you have is immediate then the final bit is 1in the command.
If you have immediate and other unsolicited (if enabled!) then set F to 0.

2.3.1 has been fixed accordingly.

Regards,
Julo

[email-masked] (Sandeep Joshi) on 09-05-2001 01:56:25

Please respond to [email-masked] (Sandeep Joshi)

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: iSCSI: immediate data

Umm.....Julian replied to this one and said the final bit on ScsiCmd
would indicate it.   Apparently, a single command can now send
the unsolicited data both with the command and in separate PDUs.

I cant seem to find the email but I believe Sec 2.3.1 was changed
accordingly.  Julian..?

-Sandeep

> The intention is that if an initiator requests to send immediate data
(and is
> granted the request), then it will always send immediate data.
>
> It sounds like you are asking for wishy washy mode... sometimes send
immediate
> data, sometimes not.
>
> -Matt
>
> Sandeep Joshi wrote:
> >
> > Julian,
> >
> > I had a follow-up question on an old thread.
> >   http://ips.pdl.cs.cmu.edu/mail/msg03373.html
> >
> > The initiator is allowed to send firstburst in immediate
> > or in separate PDUs...but can it do neither ?  I dont
> > see any statement to the effect that it MUST send a
> > firstburst.
> >
> > Here's a possible problem :
> > 1) FirstBurst is 4K
> > 2) Expected data length of command is 16K
> > 3) Initiator sends the Scsi command without immediate
> >    data.   (final flag on Scsi command is not set)
> >    And it decides to send no further data PDUs.
> >
> > The target does not know if R2Ts can be sent since it does
> > not know if any unsolicited PDUs are expected.
> >
> > Perhaps the semantics on the final flag on SCSI command
> > need to be changed to indicate that no unsolicited data
> > will be sent with this command.  Currently, the flag implies
> > (Sec 2.3.1) that all the required data has been sent with
> > the command.
> >
> > And here's a typo to fix.  Appendix E (Key=immediateData)
> > The following should say "initialR2T is no".
> > The table has got it right.
> >
> > > If ImmediateData is set to yes and InitialR2T is set
> > > to yes then the initiator MAY send unsolicited immediate
> > > data or one unsolicited burst of Data-OUT PDUs but
> > > MUST NOT send both immediate and a unsolicited burst of
> > > Data-OUT PDUs for any one command.
> >
> > -Sandeep

---

From: "Matt Wakeley" <[email-masked]>
Date: Wed, 09 May 2001 09:29:05 -0700

The way I interpret the question is, what if you negotiated immediate data,
but have no intention on sending immediate data for this command?  Is setting
the F bit, without sending any immediate data valid? (once again, more
options....)

-Matt

---

From: "Ayman Ghanem" <[email-masked]>
Date: Wed, 9 May 2001 13:16:14 -0500

I thought that you can not send both immediate and unsolicited data for the
same command. My understanding is that if there is immediate data and the
F-bit is not set, then the remaining has to go as solicited even
if InitialR2T=no is enabled. Is this changing from draft-06?.

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, May 09, 2001 2:12 AM
> To: Sandeep Joshi
> Cc: [email-masked]; [email-masked]

---

From: "Ayman Ghanem" <[email-masked]>
Date: Fri, 11 May 2001 15:35:17 -0500

Julian,

Could you please post the revised text for section 2.3.1, and the other
revised parts for immediate/unsolicited data (Appendix E-22)?. Thanks.

-Ayman