When I said "determined", I
did not mean "implemented". I meant that the SCSI layer is what
interprets the CDB. I didn't mean to answer to an implementation.
Eddy
-----Original Message-----
From: Alex Iannicelli
[mailto:alex.iannicelli@trebia.com]
Sent: Tuesday, July 22, 2003 1:37 PM
To: Eddy Quicksall; Dean Scoville;
Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: CDB/PDU
inconsistencies and residual counts
The
overflow/underflow is determined by the iSCSI layer. The SCSI layer simply
tries to satisfy the CDB. If the SCSI layer hands the iSCSI layer too much data
(more than ExpectedDataTransferLength)
the iSCSI layer will
mark it as overflow. If the SCSI layer does not hand the iSCSI layer
enough data (very common when sending INQUIRY) then the iSCSI layer must mark
it as an underflow.
Also,
the target must NEVER send too much data even if the SCSI layer tries to issue
more than ExpectedDataTransferLength. This data should be truncated by the iSCSI layer and marked as
overflow. Overflow does NOT indicate that the target just sent more data then
was requested in the ExpectedDataTransferLength.
-----Original Message-----
From: Eddy Quicksall
[mailto:eddy_quicksall@ivivity.com]
Sent: Tuesday, July 22, 2003 1:26 PM
To: Dean Scoville; Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: CDB/PDU
inconsistencies and residual counts
My
take is this:
The overflow/underflow is
determined by the SCSI layer. This is because the "expected data transfer
length" gives the size of the initiators buffer and the CDB gives the size
of the "attempted transfer". If the target is attempting to transfer
too much, that would be an overflow.
In some transports (like
parallel SCSI) this is not determined by the target but is determined by the
initiator driver or host adapter. In this case the target will try to stay in
data-in phase to transfer all of the data. The initiator sees this as an
overflow.
Eddy
-----Original Message-----
From: Dean Scoville
[mailto:dean.scoville@qlogic.com]
Sent: Tuesday, July 22, 2003 12:43 PM
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