RE: iSCSI: immediate data

[julian_satran@il.ibm.com]

Ayman,

The new 2.3.1 is:

2.3.1     Flags and Task Attributes

      The flags for a SCSI Command are:

      b7   (F) set to 1 when the immediate data that accompany the command
      are all the unsolicited data associated with this command. For a
      write, if Expected Data Transfer Length is larger than the Length the
      target may solicit additional data through R2T.
      b6   (R) set to 1 when input data is expected
      b5   (W) set to 1 when output data is expected
      b3-4 Reserved (MUST be 0)
      b0-2 used to indicate Task Attributes

   The Task Attributes (ATTR) can have one of the following integer values
   (see [SAM2] for details):

      0    Untagged
      1    Simple
      2    Ordered
      3    Head of Queue
      4    ACA


      The appendix is:

xx   ImmediateData

   Use: ALL
   Who: Initiator and Target

   ImmediateData=<yes|no>

   Default is yes.

   Initiator and target negotiate support for immediate data.  If
   ImmediateData is set to yes and InitialR2T is set to yes (default) then
   only immediate data are accepted in the first burst.

   If ImmediateData is set to no and InitialR2T is set to yes then the
   initiator MUST NOT send unsolicited data and the target MUST reject them
   with the corresponding response code.

   If ImmediateData is set to no and InitialR2T is set to no then the
   initiator MUST NOT send unsolicited immediate data but MAY send one
   unsolicited burst of Data-OUT PDUs.

   If ImmediateData is set to yes and InitialR2T is set to no then the
   initiator MAY send unsolicited immediate data and/or one unsolicited
   burst of Data-OUT PDUs.

   This field sets the D field in the Disconnect-Reconnect mode page. The
   value one of the D field means ImmediateData=no.

   The following table is a summary of unsolicited data options:


   +----------+-------------+--------------------------------------+
   |InitialR2T|ImmediateData| Result (up to FirstBurstSize)        |
   +----------+-------------+--------------------------------------+
   |  no      |    no       | Unsolicited data in data PDUs only   |
   +----------+-------------+--------------------------------------+
   |  no      |    yes      | Immediate & separate unsolicited data|
   |          |             |                                      |
   +----------+-------------+--------------------------------------+
   |  yes     |    no       | Unsolicited data disallowed          |
   +----------+-------------+--------------------------------------+
   |  yes     |    yes      | Immediate unsolicited data only      |
   +----------+-------------+--------------------------------------+

   Julo

"Ayman Ghanem" <aghanem@cisco.com> on 11-05-2001 23:35:17

Please respond to "Ayman Ghanem" <aghanem@cisco.com>

To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: immediate data




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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Wednesday, May 09, 2001 2:12 AM
> To: Sandeep Joshi
> Cc: matt_wakeley@agilent.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: immediate data
>
>
>
>
> 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
>
> sandeepj@research.bell-labs.com (Sandeep Joshi) on 09-05-2001 01:56:25
>
> Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
>
> To:   matt_wakeley@agilent.com
> cc:   ips@ece.cmu.edu
> 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
>
>
>
>