RE: CDB/PDU inconsistencies and residual counts

["Martin, Nick (Server Storage)" <nick.martin@hp.com>]

Title: Message

Dean,

 

I have seen some good answers to this already, but let me try to explain it from another point of view.  That of the layered SCSI subsystem in the host OS. 

 

In a layered SCSI subsystem as found in most modern operating systems, the HBA driver is normally given a request generated by a Target driver (such as a SCSI Disk class driver).  The request includes a CDB, transfer direction bits, and a buffer address and length (often in the form of a scatter/gather list).  After scheduling and processing the request, the HBA driver is responsible to return status to tell the Target driver what happened with respect to the buffer of data it requested to be transferred by the device. 

 

The purpose of the overflow-underflow indication is to tell the originator of the request whether the device attempted to transfer more, less, or exactly the same number of bytes as was specified in the buffer length of the original request to the HBA driver.   The residual count reports the variance from the buffer length.

 

In the case of the iSCSI HBA driver, the length of the buffer passed to the HBA is used as the "expected transfer length".  The iSCSI protocol enables the transfer of this number of bytes between the initiator and the iSCSI target over the wire.  If the SCSI layer in the target requests or attempts to transfer more or less than this original expected number of bytes (the length of the buffer in the original request), an underflow or overflow should be returned over the wire to the iSCSI HBA so that it can be reported to the SCSI Target driver.

 

For the case of overflow iSCSI can never transport more than expected transfer length.  For the case of underflow, iSCSI may or may not transport bytes within expected transfer length unused by the SCSI layer.

 

There are cases in which the Target driver will not know how in advance how much data the Target will attempt to return for a given CDB.  In these cases, most Target drivers will use an oversized buffer, the buffer is not filled, an underrun is reported, and the residual is the difference between the buffer size and the bytes transfered by the SCSI device.  Conversely the Target driver may intentionally or unintentionally use an undersized buffer relative to the target devices interpretation of the command contained in the CDB.

 

It should be the target driver writer's job to interpret and handle the underrun and overrun status.  These may be expected or unexpected results.  The lengths must be reported as a byte count of variance from the buffer length.  When buffer length is sent as "expected transfer length" the iSCSI target can do the residual length calculation properly.

 

Thanks,

Nick

-----Original Message-----
From: Dean Scoville [mailto:dean.scoville@qlogic.com]
Sent: Tuesday, July 22, 2003 11:43 AM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: CDB/PDU inconsistencies and residual counts

Julian,
The overflow/underflow and residual count values in Data-in and
SCSI Response PDUs are set by the target based on the expected
transfer length for the command, but should these values be set based
on the CDB (SCSI layer) or based on the PDU "expected data transfer length"
field (iSCSI layer)?

For example, suppose an initiator sends a 4 block SCSI Read command
but for some reason thinks the block size is 1024 bytes when in actuality
the disk has 512 byte blocks. The SCSI Command PDU would have an
"expected data transfer length" of value of 4096 bytes, but the target would
actually return 2048 bytes (based on the true block size). Should the target
set the underflow bit and return a residual count (based on the iSCSI PDU),
or should it return no underflow and no residual count (based on the SCSI CDB)?

The question comes up because I was running some iSCSI protocol test
scripts where the PDU "expected transfer length" and the transfer length
in the CDB were inconsistent in one of the scripts.

Another example would be if the "allocation length" field in the CDB for
an Inquiry command doesn't match the "expected data transfer length" field
in the SCSI Command PDU.

The script was in error and should be fixed, is there a desired target
behavior in such situations, given that the CDB fields are not typically parsed
by the iSCSI layer, the SCSI device may know nothing about iSCSI PDUs,
and some middle-layer may or may not know about both.

If the initiator detects that an underflow has occurred, based solely on the
amount of data received and the "expected data transfer field" in the iSCSI PDU,
but the target did not report an underflow or residual count in the SCSI response,
is the initiator allowed/expected to report an underflow to the upper layers?

Thanks,

Dean Scoville