iSCSI: plugfest4 issues

Julian Satran Julian_Satran at il.ibm.com
Thu Aug 1 00:25:48 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Julian Satran" <Julian_Satran at il.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 00289AE2C2256C08_=
Content-Type: text/plain; charset="us-ascii"


Santosh, 

I think that this behaviour should be specified by SPC3. I looked
(again) into the FCP docs and like iSCSI they do not say anything beyond

iSCSI says. Like iSCSI they specify that the field is valid when the
Oo/Uu bits are set but nothing about how those bits relate to status. 
SPC says nothing about that either  (beyond that the bits set are not
necessarily an indication of error). 

Julo 



	Santosh Rao <santoshr at cup.hp.com> 
Sent by: santoshr at hpcuhe.cup.hp.com 


08/01/2002 03:44 AM 
        
        To:        IPS Reflector <ips at ece.cmu.edu>, Julian
Satran/Haifa/IBM at IBMIL, rdr at io.iol.unh.edu 
        cc:        Robert Snively <rsnively at brocade.com>, T10 Reflector
<t10 at t10.org> 
        Subject:        Re: iSCSI: plugfest4 issues 

       



Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device. 

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


------------------------------------------------------------------------
-

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran at il.ibm.com>
To:     "Robert D. Russell" <rdr at io.iol.unh.edu>
CC:     ips at ece.cmu.edu

Bob, 

Thanks - some comments in text. Julo 


 "Robert D. Russell" <rdr at io.iol.unh.edu> 
                                           
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
 appropriate O and U bits need to be computed on all SCSI Response
 PDUs, regardless of the values in the Status and/or Response fields.

 One point of view says that the Residual Count field and the O and U
 bits appear to be strictly iSCSI values that are derived by the
 iSCSI target layer from the ExpectedDataTransferLength field of the
 SCSI Command PDU and the DataSegmentLength fields of the DataIn or
 DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
 target always computes a Residual Count value without regard to the
 Status and/or Response fields, since these are SCSI values.

 The other point of view says that the Residual Count field, and the
 O and U bits, need only be set when the Status and Response fields
 indicate that the command was completed at the target with a GOOD
 Status, and the target does not have to compute or set the Residual
 Count field and the O or U bits for other values of the Status and/or
 Response fields.

 Which is it?  In any case, could this be clarified somewhere in the
 standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them. 
The values should be valid any time the target decides to put them in. 
+++


------------------------------------------------------------------------
-
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively at brocade.com>
To:      "'Santosh Rao'" <santoshr at cup.hp.com>, 
        T10 Reflector <t10 at t10.org>, 
        Fibre Channel T11 reflector <fc at network.com>

Robert Snively wrote:
> 
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
> 
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> 
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
> 
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> 
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
> 
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> 
> Bob Snively                        e-mail:    rsnively at brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr at cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the
data
> >  phase having transferred exactly FCP_DL bytes, regardless of the
SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is
it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

-- 
Education is when you read the fine print. 
Experience is what you get if you don't.




--=_alternative 00289AE2C2256C08_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Santosh,</font>
<br>
<br><font size=2 face="sans-serif">I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond</font>
<br><font size=2 face="sans-serif">iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.</font>
<br><font size=2 face="sans-serif">SPC says nothing about that either &nbsp;(beyond that the bits set are not necessarily an indication of error). </font>
<br>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Santosh Rao <santoshr at cup.hp.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: santoshr at hpcuhe.cup.hp.com</font>
<p><font size=1 face="sans-serif">08/01/2002 03:44 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;IPS Reflector <ips at ece.cmu.edu&gt;, Julian Satran/Haifa/IBM at IBMIL, rdr at io.iol.unh.edu</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Robert Snively <rsnively at brocade.com&gt;, T10 Reflector <t10 at t10.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iSCSI: plugfest4 issues</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">Julian &amp; Robert [Russell],<br>
<br>
I raised the same query regarding RESID for FCP/FCP-2 this time last<br>
year. The response I got for FCP/FCP-2 was that RESID information shall<br>
be valid, regardless of the scsi status returned. The RESID field, can<br>
be checked by the scsi transport drivers independent of the SCSI STATUS.<br>
<br>
I have enclosed the T10 response from Rob Snivelly below on that issue.<br>
As per FC-PLDA, the RESID information is valid, regardless of the scsi<br>
status returned by the device. <br>
<br>
An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check<br>
condition, when the data transfer may have taken place and a CHECK<br>
CONDITION is returned. Also, for other CHECK CONDITION status', partial<br>
data transfer may have taken place and hence, resid information should<br>
be present.<br>
<br>
It would be good to maintain consistent behaviour across the scsi<br>
transports in this regard, since protocol bridging from iscsi to FCP<br>
domain would expect RESID information in the FCP domain, regardless of<br>
scsi status.<br>
<br>
This also allows scsi transports to remain free of SCSI command set<br>
details. (ex : the scsi transport drivers do not need to parse for CHECK<br>
CONDITION or GOO status information.)<br>
<br>
Thanks,<br>
Santosh<br>
<br>
<br>
-------------------------------------------------------------------------<br>
<br>
Subject: Re: iSCSI: plugfest4 issues<br>
Date: &nbsp; &nbsp;Thu, 1 Aug 2002 02:52:19 +0300<br>
From: &nbsp; "Julian Satran" <Julian_Satran at il.ibm.com&gt;<br>
To: &nbsp; &nbsp; "Robert D. Russell" <rdr at io.iol.unh.edu&gt;<br>
CC: &nbsp; &nbsp; ips at ece.cmu.edu<br>
<br>
Bob, <br>
<br>
Thanks - some comments in text. Julo <br>
<br>
<br>
 &nbsp;"Robert D. Russell" <rdr at io.iol.unh.edu&gt; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
Julian:<br>
<br>
Four issues came up today at the iSCSI plugfest:<br>
<br>
1. A question about whether or not the Residual Count field and the<br>
 &nbsp;appropriate O and U bits need to be computed on all SCSI Response<br>
 &nbsp;PDUs, regardless of the values in the Status and/or Response fields.<br>
<br>
 &nbsp;One point of view says that the Residual Count field and the O and U<br>
 &nbsp;bits appear to be strictly iSCSI values that are derived by the<br>
 &nbsp;iSCSI target layer from the ExpectedDataTransferLength field of the<br>
 &nbsp;SCSI Command PDU and the DataSegmentLength fields of the DataIn or<br>
 &nbsp;DataOut PDUs sent as part of this command. &nbsp;Therefore ,the iSCSI<br>
 &nbsp;target always computes a Residual Count value without regard to the<br>
 &nbsp;Status and/or Response fields, since these are SCSI values.<br>
<br>
 &nbsp;The other point of view says that the Residual Count field, and the<br>
 &nbsp;O and U bits, need only be set when the Status and Response fields<br>
 &nbsp;indicate that the command was completed at the target with a GOOD<br>
 &nbsp;Status, and the target does not have to compute or set the Residual<br>
 &nbsp;Count field and the O or U bits for other values of the Status and/or<br>
 &nbsp;Response fields.<br>
<br>
 &nbsp;Which is it? &nbsp;In any case, could this be clarified somewhere in the<br>
 &nbsp;standard, most likely in section 9.4.4.<br>
<br>
+++ Residual count fields are in fact carrioed over from the SCSI layer.<br>
I know that none of the SCSI docs specifies<br>
exactly their behavior and it strikes me as a bad idea to have protocols<br>
specify them. <br>
The values should be valid any time the target decides to put them in. <br>
+++<br>
</font>
<br><font size=2 face="Courier New"><br>
-------------------------------------------------------------------------<br>
Subject: RE: FCP_RSP Residual Checking.<br>
Date: &nbsp; &nbsp;Thu, 5 Jul 2001 13:18:42 -0700<br>
From: &nbsp; &nbsp;Robert Snively <rsnively at brocade.com&gt;<br>
To: &nbsp; &nbsp; &nbsp;"'Santosh Rao'" <santoshr at cup.hp.com&gt;, <br>
 &nbsp; &nbsp; &nbsp; &nbsp; T10 Reflector <t10 at t10.org&gt;, <br>
 &nbsp; &nbsp; &nbsp; &nbsp; Fibre Channel T11 reflector <fc at network.com&gt;<br>
<br>
Robert Snively wrote:<br>
> <br>
> > &nbsp;Is the target required to initialize the fields FCP_RESID_UNDER,<br>
> > &nbsp;FCP_RESID_OVER &amp; FCP_RESID when any I/O is completed<br>
> > &nbsp;without the data phase having transferred exactly<br>
> > &nbsp;FCP_DL bytes, regardless of the SCSI Status being returned ?<br>
> <br>
> > &nbsp;When the target generates a CHECK CONDITION on an I/O<br>
> > &nbsp;and may have returned less than FCP_DL bytes in the data<br>
> > &nbsp;phase for that I/O, is it<br>
> > &nbsp;required to set the FCP_RESID_UNDER to 1 and indicate the number of<br>
> > &nbsp;bytes not transferred in the FCP_RESID field?<br>
> <br>
> The intent is that the answer to your second question is:<br>
> FCP_RESID should appropriately regardless of the SCSI Status<br>
> being returned. &nbsp;The classic errors of that class are those<br>
> involving successful completion with reporting, like<br>
> the "NO SENSE" and "RECOVERED ERROR" series of errors.<br>
> <br>
> ><br>
> > &nbsp;What is the behaviour initiators can expect under the above<br>
> > &nbsp;condition ?<br>
> <br>
> The intent is that there be no conflict. &nbsp;I believe that FCP-2<br>
> was a bit less bald than FC-PLDA in stating the requirement.<br>
> <br>
> > &nbsp;Is there a conflict in the behaviours described by FCP/FCP-2<br>
> > &nbsp;&amp; FC-PLDA ?<br>
> ><br>
> <br>
> Bob Snively &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;e-mail: &nbsp; &nbsp;rsnively at brocade.com<br>
> Brocade Communications Systems &nbsp; &nbsp; phone: &nbsp;408 487 8135<br>
> 1745 Technology Drive<br>
> San Jose, CA 95110<br>
> <br>
> > &nbsp;-----Original Message-----<br>
> > &nbsp;From: Santosh Rao [mailto:santoshr at cup.hp.com]<br>
> > &nbsp;Sent: Thursday, July 05, 2001 12:15 PM<br>
> > &nbsp;To: T10 Reflector; Fibre Channel T11 reflector<br>
> > &nbsp;Subject: FCP_RSP Residual Checking.<br>
> ><br>
> ><br>
> > &nbsp;All,<br>
> ><br>
> > &nbsp;I've got a question on target behaviour while sending a<br>
> > &nbsp;CHECK CONDITION<br>
> > &nbsp;SCSI status in its FCP_RSP IU.<br>
> ><br>
> > &nbsp;Is the target required to initialize the fields FCP_RESID_UNDER,<br>
> > &nbsp;FCP_RESID_OVER &amp; FCP_RESID when any I/O is completed without the data<br>
> > &nbsp;phase having transferred exactly FCP_DL bytes, regardless of the SCSI<br>
> > &nbsp;Status being returned ?<br>
> ><br>
> > &nbsp;When the target generates a CHECK CONDITION on an I/O and may have<br>
> > &nbsp;returned less than FCP_DL bytes in the data phase for that I/O, is it<br>
> > &nbsp;required to set the FCP_RESID_UNDER to 1 and indicate the number of<br>
> > &nbsp;bytes not transferred in the FCP_RESID field?<br>
> ><br>
> > &nbsp;FC-PLDA Section 8.2.4.1 states that :<br>
> > &nbsp;"SCSI targets that transfer less than FCP_DL bytes during<br>
> > &nbsp;the FCP_DATA<br>
> > &nbsp;IUs shall set the FCP_RESID_UNDER to 1".<br>
> ><br>
> > &nbsp;No exceptions are specified in the case of a CHECK CONDITION in the<br>
> > &nbsp;above definition, implying that FCP_RSP residual checking can be<br>
> > &nbsp;performed irrespective of the SCSI Status that was returned in the<br>
> > &nbsp;FCP_RSP.<br>
> ><br>
> > &nbsp;However, the wording descriptions of FCP_RESID_UNDER,<br>
> > &nbsp;FCP_RESID_OVER &amp;<br>
> > &nbsp;FCP_RESID in SCSI-FCP &amp; FCP-2 are not as stringent as<br>
> > &nbsp;FC-PLDA and do not<br>
> > &nbsp;mandate that FCP_RESID_UNDER shall be set when the data<br>
> > &nbsp;transferred is <<br>
> > &nbsp;FCP_DL.<br>
> ><br>
> > &nbsp;What is the behaviour initiators can expect under the above<br>
> > &nbsp;condition ?<br>
> > &nbsp;Is there a conflict in the behaviours described by FCP/FCP-2<br>
> > &nbsp;&amp; FC-PLDA ?<br>
> ><br>
> > &nbsp;Thanks,<br>
> > &nbsp;Santosh Rao<br>
> ><br>
<br>
-- <br>
Education is when you read the fine print. <br>
Experience is what you get if you don't.<br>
</font>
<br>
<br>
--=_alternative 00289AE2C2256C08_=--




More information about the T10 mailing list