RE: iSCSI: SCSI Response Hdr - Sense Data Length

[Michael Schoberg <michael_schoberg@cnt.com>]

I believe you misunderstood the point I was emphasizing. The current format requires the initiator to parse two headers before it knows where all the messages begin.  Assuming an initiator is trying to be efficient and avoid data copies as much as possible, it would do something like this:

1. Read in the BHS.  Determine that it is a iSCSI SCSI Response.
2. <stop>  Issue the read for the additional 2 bytes containing Sense Length.
3. <stop>  Determine the sense data length for SCSI Response Messages.  Proceed by transferring the available sense data into the sense buffer and the response data into the response buffer.
4. Complete.

After step #3, the initiator can setup the scatter/gather list of where the sense-data and receive data should be placed.

 

Ideally, you want as few "stops" as possible.  Once the length of all segments are known, it's generally trivial to program where the hardware should put everything.  If you allow several intermediate steps (the worst-case scenario), then some sort of logic (software/hardware) will have to decide how to handle the PDU during a stop. 

 

By putting the sense-length in the BHS, you avoid the additional stop-and-check-the-header step of #3.  I really see no advantage to putting the sense-length out of the BHS!  Once you know where everything belongs, it's not unusual to be able to program hardware to handle the rest of the message segments:

1. Read in the BHS.
2. <stop> Program hardware to handle Sense and Response Data.
3. Complete

I also don't like seeing statements like: "in most of the cases".  By putting extra complexity in the design, it means that all software and hardware MUST support it.  By saying that most of the time you won't use the feature or message, just says the extra complexity was a waste.

 

"In most of the cases the data segment will contain nothing." 

 

I see nothing in the draft that prevents targets from loading sense and/or data the SCSI Response (0x21) message.  In fact, it seems to make sense that an SCSI Command (0x01) might be responded to with a SCSI Response (0x21) by default with some implementations.

 

Thanks.

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 22, 2002 2:48 PM
To: Michael Schoberg
Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu
Subject: Re: iSCSI: SCSI Response Hdr - Sense Data Length

The SCSI response needs anyhow a separate handler.
In most of the cases the data segment will contain nothing.   
When it contains something it may be sense or response (or sometime in the future both).

So in most of the case you will have to check one field and only on exceptions two.

Julo

Michael Schoberg <michael_schoberg@cnt.com> Sent by: owner-ips@ece.cmu.edu 04/22/2002 08:42 PM Please respond to Michael Schoberg

To:        "IPS Reflector (E-mail)" <ips@ece.cmu.edu>         cc:                 Subject:        iSCSI: SCSI Response Hdr - Sense Data Length

A question concerning the iSCSI - SCSI Response headers (op-0x21).  When the
target sends it with a DataSegmentLength > 0, it must automatically include
a two-byte sense data header preceding any response data.  This means all
response data will be offset by this two byte header even if the
sense-length is zero.  Why wasn't the sense data length put in the byte 20
range of the response (currently marked reserved)?  This would've avoided
the extra work for initiators to have to handle response data for this PDU
type differently from the others.  Essentially, this forces another header
handler on the initiator side for the two header bytes describing the sense
data length.