RE: Data in SCSI Response or SCSI Data

["Y P Cheng" <ycheng@advansys.com>]

> From:  Stephen Bailey
> So, while I think concatenating status and data in its general form is
> not a good idea, a good-status fast path (like the success bit) is
> definitely the right way to think about it.  Nonsuccess SCSI status is
> so rare that any compromise you can make in the nonsuccess path to
> make the success path go faster is worth it.

To support your argument, let me describe how the hardware works in setting
the good status flag bit:

In hardware for each outgoing datagram, there is an exchange table entry
describing the payload size, the total data amount (packet size), and the
information to build a media header plus a "device header" which typically
is protocol dependent.  The microcode builds the Upper Level Protocol (ULP)
header.  Therefore, setting a "Good Status" flag bit in a iSCSI header is a
function of the microcode of a NIC adapter.  When a packet is broken down
into multiple frames (or messages) the hardware is smart not to repeat the
ULP header.

Therefore, for a successful read, the microcode builds the iSCSI header with
a good status flag bit set and activate the hardware to send the data out.
The hardware puts the iSCSI header in the first frame of the data packet.
The microcode reports back to the NIC device driver that everything is done.
For an unsuccessful read, the microcode first transmits whatever data it
has.  Then, it builds a status message with sense data.  Finally, it
activates the hardware to ship it out -- with proper media and IP headers --
and reports to the NIC device driver.

> From: David Robinson
> iSCSI should not try to end-run congestion control, creating and managing
> multiple connections may cause unexpected interactions with congestion
> control algorithms and other QOS mechanisms.  I don't know this to
> be true but we must be certain we are not causing problems before
> we go down this path.

Yes, iSCSI should only deal with SCSI command, data, and status
encapsulation in IP packets.  Let TCP or other ULP's deal with reliable
delivery, multi-path, load balance, security, transmission errors, and
recovery.