Clarification on SCSI presented data length for residual overflow/underflow determination

Paul Hughes phughes at solidfire.com
Fri Jun 13 09:40:24 PDT 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406131_f.htm">HTML-formatted message</a>

Thanks for the response, but I'm not sure if you're implying there is no
residual because the command was never processed, and I don't see where RFC
3720 or RFC 5048 state that no residual should be reported when a command
is not processed.  Section 10.4.1 of RFC 3720 states:
bit 5 - (O) set for Residual Overflow. In this case, the Residual
Count indicates the number of bytes that were not transferred
because the initiator’s Expected Data Transfer Length was not
sufficient. For a bidirectional operation, the Residual Count
contains the residual for the write operation.
bit 6 - (U) set for Residual Underflow. In this case, the Residual
Count indicates the number of bytes that were not transferred out
of the number of bytes that were expected to be transferred. For
a bidirectional operation, the Residual Count contains the
residual for the write operation.
Ignoring the unit attention scenario for now, if a single block write
command is enabled and begins processing but then fails with Check
Condition status (e.g. Illegal Request, Invalid Field in CDB sense data),
would the SPDTL be zero (resulting in a residual underflow of 512 bytes)
regardless of whether immediate data was transferred with the write
command, or would the SPDTL be 512 if 512-bytes of immediate data were
transferred (resulting in no residual underflow/overflow being reported)?
On Thu, Jun 12, 2014 at 9:04 PM, Black, David <david.black at emc.com> wrote:
> Paul,
>
>
>
> Well, the command has not actually been processed by the device server in
>
> the example in your email:
>
>
>
> > For example, the iSCSI layer receives a SCSI command PDU containing a
> CDB for a write of
>
> > a single 512-byte block and an EDTL of 512, and then calls into the SCSI
> layer to process the
>
> > command.  If the SCSI layer completes the command with SCSI Check
> Condition status due
>
> > to a unit attention condition,
>
>
>
> Unit attention (UA) processing occurs when the command is enabled, but
> before
>
> the command is actually processed - see item e) at the end of 5.14.1 in
> SAM-5.
>
>
>
> In this case, I would expect both the U and O bits the iSCSI SCSI Response
>
> PDU to be clear, so neither underrun nor overrun is reported.
>
>
>
> Initiator (application client) code is responsible for understanding that
> UA
>
> delivery occurs before any command processing and hence has to retry any
>
> command that reports a UA.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
> Hughes
> *Sent:* Thursday, June 12, 2014 6:31 PM
> *To:* t10 at t10.org
> *Subject:* Clarification on SCSI presented data length for residual
> overflow/underflow determination
>
>
>
> For iSCSI, RFC 5048 states:
>
>
>
> 2.1.	Definitions
>
>
>
>    SCSI-Presented Data Transfer Length (SPDTL)
>
>	SPDTL is the aggregate data length of the data that the SCSI layer
>
>	logically "presents" to the iSCSI layer for a Data-In or Data-Out
>
>	transfer in the context of a SCSI task.  For a bidirectional task,
>
>	there are two SPDTL values -- one for Data-In and one for Data-
>
>	Out.  Note that the notion of "presenting" includes immediate data
>
>	per the data transfer model in [SAM2], and excludes overlapping
>
>	data transfers, if any, requested by the SCSI layer.
>
>
>
> 3.1.1.  Overview
>
>
>
>    SCSI-Presented Data Transfer Length (SPDTL) is the term this document
>
>    uses (see Section 1.1 for definition) to represent the aggregate data
>
>    length that the target SCSI layer attempts to transfer using the
>
>    local iSCSI layer for a task.  Expected Data Transfer Length (EDTL)
>
>    is the iSCSI term that represents the length of data that the iSCSI
>
>    layer expects to transfer for a task.  EDTL is specified in the SCSI
>
>    Command PDU.
>
>
>
>    When SPDTL = EDTL for a task, the target iSCSI layer completes the
>
>    task with no residuals.  Whenever SPDTL differs from EDTL for a task,
>
>    that task is said to have a residual.
>
>
>
>    If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the
>
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
>
>    be set to the numerical value of (SPDTL - EDTL).
>
>
>
>    If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
>
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
>
>    be set to the numerical value of (EDTL - SPDTL).
>
>
>
>    Note that the Overflow and Underflow scenarios are independent of
>
>    Data-In and Data-Out.  Either scenario is logically possible in
>
>    either direction of data transfer.
>
>
>
>
>
> Given an example where the iSCSI layer receives a SCSI command PDU
> containing a CDB for a read of a single 512-byte block and an EDTL of 512,
> and then calls into the SCSI layer to process the command.  If the SCSI
> layer completes the command with SCSI Check Condition status due to a unit
> attention condition, would the SPDTL be zero because the SCSI layer never
> attempted to transfer data using the iSCSI layer?  If so, then an underflow
> with residual count of 512 should be signaled, correct?
>
>
>
> I'm not sure what was meant by 'the notion of "presenting" includes
> immediate data' in Section 2.1.  Does this mean that the SPDTL is the same
> regardless of whether immediate data was received or not?
>
>
>
> For example, the iSCSI layer receives a SCSI command PDU containing a CDB
> for a write of a single 512-byte block and an EDTL of 512, and then calls
> into the SCSI layer to process the command.  If the SCSI layer completes
> the command with SCSI Check Condition status due to a unit attention
> condition, would the SPDTL be zero because the SCSI layer never attempted
> to transfer data using the iSCSI layer, or does the SPDTL depend on whether
> immediate data was already transferred in the iSCSI command PDU?
>
>
>
> Thanks!
>
>
>
> --
> *Paul Hughes*
> *Senior Software Engineer, SolidFire, Inc.*
> e: phughes at solidfire.com
> *Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play&gt;â„¢*
>
-- 
*Paul HughesSenior Software Engineer, SolidFire, Inc.*
e: phughes at solidfire.com
*Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play&gt;**â„¢*



More information about the T10 mailing list