|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: plugfest4 issuesDavid, the current text already says this but how about? The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set the residual count and initiators may use it when the response code is "completed at target" (even if the status returned is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo
Julian, Text is ok, but please add a sentence to avoid the confusion over Status that occurred at the plugfest - SCSI permits a residual count to be returned for status values other than GOOD. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 03, 2002 1:14 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy. The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue). Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count. That is why I would suggest the following text: The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo
Julian, Matching FCP's wording resulted in a "go ask the expert" algorithm for figuring out what is required - we ought to do better, and this is an iSCSI protocol issue. What I'm looking for in 9.4 is: - Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked by the Initiator when the Response is "Command Completed at Target" no matter what the value of the Status field is. - SCSI permits Residual Counts to be returned for Status values other than GOOD; see [SPC2]. I believe that both of these are implied by the current text, but since this caused confusion at the plugfest, we ought to spell it out. Thanks, --David --------------------------------------------------- -----Original Message-----
Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). Thanks, --David --------------------------------------------------- -----Original Message-----
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@il.ibm.com> To: "Robert D. Russell" <rdr@io.iol.unh.edu> CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" <rdr@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@brocade.com> To: "'Santosh Rao'" <santoshr@cup.hp.com>, T10 Reflector <t10@t10.org>, Fibre Channel T11 reflector <fc@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@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@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.
Home Last updated: Tue Aug 06 22:18:50 2002 11539 messages in chronological order |