RE: Data in SCSI Response or SCSI Data

[julian_satran@il.ibm.com]

The status message is in the iSCSI header (not after the data).
If the status is bad and/or includes sense data it should be sent
separately.

Julo

"Y P Cheng" <ycheng@advansys.com> on 25/08/2000 23:23:00

Please respond to "Y P Cheng" <ycheng@advansys.com>

To:   "Robert Reynolds" <robertr@Crossroads.com>, ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: Data in SCSI Response or SCSI Data




> From: Robert Reynolds
>
>  Although it's true that 99.99% of reads will be successful it is
>  not always true that the status can be implemented with one bit.
>  If you are doing Tape Reads using variable block records then
>  you also need to ensure that the underrun data length is included
>  as part of the status.

No, this is not a problem.  In reading, the SCSI initiator knows how many
bytes it has received and will report the underflow condition correctly.
The SCSI target needs not report the transfer size.  On a write operation,
the SCSI target always return a status message in which it stores the
residue count, the amount of data not written.

>  Another thought on why it would be a good thing to combine status
>  and data is for congestion control.  Either the sender has to wait
>  for more data in the window before sending the status or it is sending
>  a lot of small TCP packets containing the status which is probably
>  not what we would want to see on the network.  By combining the status
>  with the last data frame you can avoid this potential problem.

Yes.  However, this is how the hardware handles the bundled packets.

1) the whole packet is in the receive FIFO.  2148 bytes for the FC and 1500
for Ethernet.
2) the media header is decoded to get the FC or Ethernet media control
information.
3) the IP header is decoded from which we learn if there is a iSCSI, FTP,
or
VI header.
4) from the iSCSI header we direct the command and status to the microcode
and move the data to a pre-defined receive buffer (This is where TCP/RDMA
will be handled.)

Note, at step 4, the hardware parses the packet.  Normally, the hardware
does one thing well repeatedly.  If there is a status message tagged along
the data message, the hardware must first perform DMA data transfer. Then,
it repeats step 4 for the status message.  It is quite doable if we got a
programmable sequencer in the hardware.  However, what happen if we got a
DMA transfer error, how do we report to the microcode that besides the DMA
transfer error, there is still a status message left in the receive FIFO?
It gets a little more complicated.