[T11.3] FCP-3 Work Item #4

Robert Snively rsnively at brocade.com
Wed Sep 24 13:56:45 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C382DE.5D0A00E5
Content-Type: text/plain

Paul, 

Horst is right. 

The proper view of this is that the FC-4 layer protocol 
defined by FCP has FC components that define the permitted 
Fibre Channel and application behavior and SAM compliant 
components that define the permitted SCSI behavior. 

Buffer allocations can routinely be made with incomplete 
knowledge of the expected SCSI data length, and it is these 
buffer allocations that must protect themselves and warn of their 
violation.  FCP_DL is the Fibre Channel mechanism for that. 

In the tape write case you describe, the buffer length is the SCSI 
data length, and FCP_DL will always exactly equal the data to 
be transferred.  However, this is not a general behavior. 
Reads are the most dangerous, since they may transmit data 
into other buffers as the Data Buffer Pointer increments 
beyond the expected limits. 

Admittedly, most HBAs on most ordinary SCSI devices doing 
nothing special will find FCP_DL violations only during 
program development. 

I believe that the present text is still valid and does not 
need to be modified. 

I believe your suggestion 1 is not advisable because it 
requires posting a protocol failure before the protocol 
has been violated. 

I believe your suggestion 2 is not advisable because it 
forces the SCSI layer to detect potential (but not yet 
definite) violations of the transmission protocol. 

I believe your suggestion 3 is not advisable because it 
conflicts with previous successful FCP implementation. 
ADT is not a good counter-example, since it uses a simpler 
protocol with a private physical layer and a private 
layering structure.  FCP on the other hand is one of many 
protocols that a Fibre Channel HBA supports, each with its 
own mechanism for managing FC buffering and transfers. 

Bob 



> -----Original Message----- 
> From: Paul.A.Suhler at certance.com [ mailto:Paul.A.Suhler at certance.com
 ] 
> Sent: Tuesday, September 23, 2003 11:27 AM 
> To: t10 at t10.org; t11_3 at mail.t11.org 
> Subject: [T11.3] FCP-3 Work Item #4 
> 
> 
> INCITS T11.3 Mail Reflector 
> ******************************** 
> I don't recall an in-depth discussion of this item at the 
> meeting and the 
> minutes aren't out yet, so I thought that I'd raise a question here. 
> 
> The issue is what to do with an FCP_CMND IU in which the CDB 
> specifies a 
> data transfer longer than FCP_DL: 
> 
>    4) - clause 9.3 
>    ... The target shall never request or deliver data outside 
> the buffer 
>    length defined by FCP_DL. If the command requested that data beyond

>    FCP_DL be transferred, the FCP_RSP IU shall contain the 
> FCP_RESID_OVER 
>    bit set to one. The command is completed normally except that data 
>    beyond the FCP_DL count shall not be transferred and that the 
>    appropriate overrun condition is presented. See 9.4.4. 
> 
>    How can the command ever request that data beyond FCP_DL 
> be transferred? 
>    Maybe this would be for example, when a variable length read type 
>    command is issued to a tape device that results in data 
> larger than the 
>    provided FCP_DL? 
> 
> I'd argue that the last case should not occur.  The HBA 
> driver should be 
> able to set FCP_DL correctly. 
> 
> Nevertheless, a target must handle the error.  My main 
> concern is a write 
> to tape where FCP_DL is too short.  I believe that 
> transferring and writing 
> less data than the CDB specifies would be much worse than 
> simply rejecting 
> the command.  I see three possible solutions: 
> 
> 1.  Reject the command with a transport-level error, i.e., 
> RSP_CODE != 0. 
> Perhaps 02h, "FCP_CMND fields invalid" 
> 
> 2.  Reject the command with a status of Check Condition / 
> Illegal Request 
> and an appropriate ASC 
> 
> 3.  Obsolete the FCP_DL field and ignore it, letting the target always

> transfer the amount of data specified in the CDB.  We're 
> taking this path 
> in ADT by not putting in such a field. 
> 
> 
> Thanks, 
> 
> Paul Suhler 
> Senior Staff Firmware Engineer 
> Certance 
> 1650 Sunflower Avenue 
> Costa Mesa, California  92626 
> (714) 641-2485 (voice) 
> (714) 966-7328 (fax) 
> 
> 
> 
> To Unsubscribe: 
> mailto:t11_3-request at mail.t11.org?subject=unsubscribe
<mailto:t11_3-request at mail.t11.org?subject=unsubscribe>  
> 
> 
> 


------_=_NextPart_001_01C382DE.5D0A00E5
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 RE: [T11.3] FCP-3 Work Item #4 Paul, Horst is right. The proper view of this is that the FC-4 layer = protocol 
defined by FCP has FC components that define the = permitted 
Fibre Channel and application behavior and SAM = compliant 
components that define the permitted SCSI = behavior. Buffer allocations can routinely be made with = incomplete 
knowledge of the expected SCSI data length, and it = is these 
buffer allocations that must protect themselves and = warn of their 
violation.  FCP_DL is the Fibre Channel = mechanism for that. In the tape write case you describe, the buffer = length is the SCSI 
data length, and FCP_DL will always exactly equal = the data to 
be transferred.  However, this is not a general = behavior. 
Reads are the most dangerous, since they may = transmit data 
into other buffers as the Data Buffer Pointer = increments 
beyond the expected limits. Admittedly, most HBAs on most ordinary SCSI devices = doing 
nothing special will find FCP_DL violations only = during 
program development. I believe that the present text is still valid and = does not 
need to be modified. I believe your suggestion 1 is not advisable because = it 
requires posting a protocol failure before the = protocol 
has been violated. I believe your suggestion 2 is not advisable because = it 
forces the SCSI layer to detect potential (but not = yet 
definite) violations of the transmission = protocol. I believe your suggestion 3 is not advisable because = it 
conflicts with previous successful FCP = implementation. 
ADT is not a good counter-example, since it uses a = simpler 
protocol with a private physical layer and a = private 
layering structure.  FCP on the other hand is = one of many 
protocols that a Fibre Channel HBA supports, each = with its 
own mechanism for managing FC buffering and = transfers. Bob 

> -----Original Message----- 
> From: Paul.A.Suhler at certance.com [mailto:Paul.A.Suhler at certance= .com] 
> Sent: Tuesday, September 23, 2003 11:27 = AM 
> To: t10 at t10.org; t11_3 at mail.t11.org 
> Subject: [T11.3] FCP-3 Work Item #4 
> 
> 
> INCITS T11.3 Mail Reflector 
> ******************************** 
> I don't recall an in-depth discussion of this = item at the 
> meeting and the 
> minutes aren't out yet, so I thought that I'd = raise a question here. 
> 
> The issue is what to do with an FCP_CMND IU in = which the CDB 
> specifies a 
> data transfer longer than FCP_DL: 
> 
>    4) - clause 9.3 
>    ... The target shall never = request or deliver data outside 
> the buffer 
>    length defined by FCP_DL. If = the command requested that data beyond 
>    FCP_DL be transferred, the = FCP_RSP IU shall contain the 
> FCP_RESID_OVER 
>    bit set to one. The command = is completed normally except that data 
>    beyond the FCP_DL count shall = not be transferred and that the 
>    appropriate overrun condition = is presented. See 9.4.4. 
> 
>    How can the command ever = request that data beyond FCP_DL 
> be transferred? 
>    Maybe this would be for = example, when a variable length read type 
>    command is issued to a tape = device that results in data 
> larger than the 
>    provided FCP_DL? 
> 
> I'd argue that the last case should not = occur.  The HBA 
> driver should be 
> able to set FCP_DL correctly. 
> 
> Nevertheless, a target must handle the = error.  My main 
> concern is a write 
> to tape where FCP_DL is too short.  I = believe that 
> transferring and writing 
> less data than the CDB specifies would be much = worse than 
> simply rejecting 
> the command.  I see three possible = solutions: 
> 
> 1.  Reject the command with a = transport-level error, i.e., 
> RSP_CODE !=3D 0. 
> Perhaps 02h, ;FCP_CMND fields = invalid; 
> 
> 2.  Reject the command with a status of = Check Condition / 
> Illegal Request 
> and an appropriate ASC 
> 
> 3.  Obsolete the FCP_DL field and ignore = it, letting the target always 
> transfer the amount of data specified in the = CDB.  We're 
> taking this path 
> in ADT by not putting in such a field. 
> 
> 
> Thanks, 
> 
> Paul Suhler 
> Senior Staff Firmware Engineer 
> Certance 
> 1650 Sunflower Avenue 
> Costa Mesa, California  92626 
> (714) 641-2485 (voice) 
> (714) 966-7328 (fax) 
> 
> 
> 
> To Unsubscribe: 
> mailto:= t11_3-request at mail.t11.org?subject=3Dunsubscribe 
> 
> 
> 
------_=_NextPart_001_01C382DE.5D0A00E5--




More information about the T10 mailing list