Re:

[julian_satran@il.ibm.com]

Barry,

Immediate data is "attached to the command". If your unsolicited data (the
so called initial burst) is larger that what you are ready to commit to a
single PDU you can send several PDUs with the  last having the F bit. After
that the target can decide that it wants more and send an R2T or send
status.

You are no supposed to send both immediate and separate PDU.

I admit that the text is bit confusing (in 1.2.5)  and there is an error
also in the appendix.
2.7.1 talk about unsolicited data (not immediate) (the context is data
PDUs).

The new version of 1.2.5 now reads:

   Unsolicited data can be sent as part of an iSCSI command PDU ("immediate
   data") or an in separate iSCSI data PDUs.  An initiator may send
   unsolicited data either as immediate (up to the negotiated maximum PDU
   size - DataPDULength - disconnect-reconnect mode page) or in a separate
   PDU sequence (up to the negotiated limit - FirstBurstSize -
   disconnect-reconnect mode page). All subsequent data have to be
   solicited.  The maximum size of an individual data PDU or the
   immediate-part of the initial unsolicited burst as well as the initial
   burst size MAY be negotiated at login.


Thanks,
Julo

"Barry Reinhold - Lamprey" <bbr@lampreyNetworks.com> on 29/01/2001 16:34:30

Please respond to "Barry Reinhold - Lamprey" <bbr@lampreyNetworks.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Jon Sreekanth" <jon.sreekanth@trebia.com>, "James Smart"
      <james.smart@trebia.com>
Subject:





Issue:

I am unclear on how to respond to an iSCSI SCSI command PDU when there is
immediate data but not enough to meet the requirements of the IO operation
as given in the expected data transfer length field. Should an R2T be
issued
or not?

Background:

Clause 2.7.1 in 03 reads:

"2.7.1 F (Final) bit

   This bit is 1 for the last PDU of immediate data or the last PDU of a
   sequence answering a R2T."

This suggests that immediate data can extend beyond the iSCSI SCSI CMD PDU
(there is no final bit on the command PDU)but the closet thing we have to a
definition for immediate data, which is in clause 1.2.5 below, suggests
that
immediate data is limitted to the command PDU:


"Outgoing SCSI data (initiator to target - user data or command
   parameters) will be sent as either solicited data or unsolicited
   data.  Solicited data are sent in response to Ready To Transfer (R2T)
   PDUs. Unsolicited data can be part of an iSCSI command PDU
   ("immediate data") or an iSCSI data PDU.  An initiator may send
   unsolicited data (immediate or in a separate PDU) up to the
   negotiated limit (initial burst size - mode page 02h). All subsequent
   data have to be solicited.  The maximum size of an individual data
   PDU or the immediate-part of the initial unsolicited burst MAY be
   negotiated at login (maximum connect size - mode page 02h)."

Unsolicited data is bounded in a number of ways, but most significant to
this issue is in the description of the login key useR2t which states:

"Note than only the first
   outgoing data item (either immediate data or a separate PDU) can be
   sent unsolicited by a R2T."


Given the above it is unclear to me if the concept of immediate data is:

1. Write data that can be sent without an R2T (unsolicited write data)and
starts in the command PDU.
2. Write data that is entirely contained within the command PDU. (my
initial
concept of immediate data)
3. The non-zero portion of data, in a possible multi-PDU write operation,
that is contained in the iSCSI SCSI command PDU. Where the remaining PDUs
of
the write operation must be solicited with an R2T.

Given the current definition of the Final bit and the current limits on
unsolicited data it is unclear to me what a target should do when receiving
an iSCSI SCSI command PDU that has immediate data in it, but not sufficient
data to meet the expected data transfer length specificied in the command.
Does an R2T go out of not?

Barry Reinhold
603-659-0885