FCP-2 recovery problem

Binford, Charles cbinford at lsil.com
Fri Jun 23 07:46:30 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Binford, Charles" <cbinford at lsil.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_01BFDD21.D67FF012
Content-Type: text/plain; charset="iso-8859-1"

Carl, I fail to see how adding one bit does any more than extend the
OX_ID field by one bit.  Now instead of roll over at 64k, you roll over
at 128k.  However, in many implementations I'm familiar with the OX_ID
range used is much smaller.  This is because people are using it as
designed by the FC committee - to be an HW lookup index to the resources
associated with the exchange.  Most FC chips don't have resources to
support 64K exchanges per d_id and thus the real range for OX_ID is much
smaller.  (We'd be guilty of designing a very limiting architecture if
the typical implementation was actually bumping up against the
limitations of the standard.)

The other point (which is more important to this discussion) I want to
make about OX_ID assignments is that because it is an index into chip
resources the management of it is often in a very low layer of the
driver that has no knowledge of the payload.  The layer building the
FCP_CMD payload has no clue what OX_ID is going to be assigned, the
layer assigning the OX_ID has no clue about any 'Hermann' bit that may
or may not need to be set.

While I believe Dave Baldwin's solution will work, I also have some
reservations about it.  Again it is the layering thing.  FC driver
interfaces would have to be changed to allow the upper layer to specify
a value to be placed in the header (built by a lower layer).  I'd rather
place the new data in the payload that is built by the same layer that
understands what is going on.

********* here is my proposal ********** 
For any command that can't be simply aborted and retried (i.e. not
Inquiry, etc.) use a non-zero CRN value.  Define the reserved byte in
the REC payload to hold the CRN value if non-zero.  A target receiving
an REC with a non-zero "CRN" value shall match it and the OX_ID before
determining if to ACC or RJT the command.

This is basically the same thing as Dave's proposal with the following
modification: 
- new data in payload instead of header 
- on 8 bits instead of 32 

I'd argue that 8 bits is sufficient for the same reasons it is large
enough for command delivery ordering.  There it not a need to queue
larger than 255 for sequential devices.

Comments?? 

Charles Binford 
LSI Logic Storage Systems 
(316) 636-8566 


-----Original Message----- 
From: Zeitler, Carl [ mailto:Carl.Zeitler at COMPAQ.com
 ] 
Sent: Friday, June 23, 2000 8:04 AM 
To: 'Baldwin, Dave' 
Cc: T10 at t10.org; 'FC Reflector' 
Subject: RE: FCP-2 recovery problem 


* From the T10 Reflector (t10 at t10.org), posted by: 
* "Zeitler, Carl" <Carl.Zeitler at compaq.com> 
* 

I made 2 boo boos.  Dave Ford it right.  The VI Handles are in the
Device 
Header.  The payloads of REC/SRR are not changed under your method. 

In my mind, the proposed solution is elegant and works, but the elegance
is 
not needed to solve this Class 3 error recovery corner case for tapes.
I 
believe it preferable to preserve the Parameter field in the frame
header 
for more pervasive problems and for future expansion. 

 The only thing necessary to solve this problem is to be able to
distinguish 
OX_ID A from OX_ID A'.  A single bit, think of it as an extension of the

OX_ID, is all that is necessary to make this distinction.  The 
implementation (Initiator) would have to remember the setting of this
bit 
(lets call it Herman) on a per OX_ID basis and flip Herman on the next
usage 
of the  same OX_ID. 

Herman can be specified by Byte 1, Bit 7 in the FCP_CMD IU, which is 
currently reserved. 

Herman can be specified in Byte 5, Bit 7 of the REC Payload, which is 
currently reserved.  The REC is ACCed or Rejected as a function of the 
presence of the OX_ID and the setting of Herman in the Target (Initiator
for 
the FCP Confirm case).  There is no need to return Herman in the
ACC/Reject 
Payload. 
  
Herman can be specified in byte 13, bit 7 of the SRR Payload, which is 
currently reserved.  The SRR is ACCed or Rejected as a function of the 
presence of the OX_ID and the setting of the bit in the Target. There is
no 
need to return Hermman in the ACC/Reject Payload. 

I believe this solves the problem and should not impact current 
implementations, assuming they are not checking reserve fields or
assuming 
that they are 0. REC will have to be changed in FC_FS if it has already
been 
incorporated.  Other changes would be contained in FCP-2. 


Regards, Carl 

Carl Zeitler 
Compaq Computer Corporation 
MS 150801, 20555 SH249, Houston, TX 77070 
Phone:281-518-5258 Fax: 281-514-5270 
E-Mail: Carl.Zeitler at compaq.com 


------_=_NextPart_001_01BFDD21.D67FF012
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: Quoted-Printable

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

RE: FCP-2 recovery problem Carl, I fail to see how adding one bit does any more = than extend the OX_ID field by one bit.  Now instead of roll over = at 64k, you roll over at 128k.  However, in many implementations = I'm familiar with the OX_ID range used is much smaller.  This is = because people are using it as designed by the FC committee - to be an = HW lookup index to the resources associated with the exchange.  = Most FC chips don't have resources to support 64K exchanges per d_id = and thus the real range for OX_ID is much smaller.  (We'd be = guilty of designing a very limiting architecture if the typical = implementation was actually bumping up against the limitations of the = standard.) The other point (which is more important to this = discussion) I want to make about OX_ID assignments is that because it = is an index into chip resources the management of it is often in a very = low layer of the driver that has no knowledge of the payload.  The = layer building the FCP_CMD payload has no clue what OX_ID is going to = be assigned, the layer assigning the OX_ID has no clue about any = 'Hermann' bit that may or may not need to be set. While I believe Dave Baldwin's solution will work, I = also have some reservations about it.  Again it is the layering = thing.  FC driver interfaces would have to be changed to allow the = upper layer to specify a value to be placed in the header (built by a = lower layer).  I'd rather place the new data in the payload that = is built by the same layer that understands what is going = on. ********* here is my proposal ********** 
For any command that can't be simply aborted and = retried (i.e. not Inquiry, etc.) use a non-zero CRN value.  Define = the reserved byte in the REC payload to hold the CRN value if = non-zero.  A target receiving an REC with a non-zero = ;CRN; value shall match it and the OX_ID before determining = if to ACC or RJT the command. This is basically the same thing as Dave's proposal = with the following modification: 
- new data in payload instead of header 
- on 8 bits instead of 32 I'd argue that 8 bits is sufficient for the same = reasons it is large enough for command delivery ordering.  There = it not a need to queue larger than 255 for sequential = devices. Comments?? Charles Binford 
LSI Logic Storage Systems 
(316) 636-8566 
-----Original Message----- 
From: Zeitler, Carl [mailto:Carl.Zeitler at COMPAQ.com] 
Sent: Friday, June 23, 2000 8:04 AM 
To: 'Baldwin, Dave' 
Cc: T10 at t10.org; 'FC Reflector' 
Subject: RE: FCP-2 recovery problem 
* From the T10 Reflector (t10 at t10.org), posted = by: 
* ;Zeitler, Carl; = <Carl.Zeitler at compaq.com> 
* I made 2 boo boos.  Dave Ford it right.  = The VI Handles are in the Device 
Header.  The payloads of REC/SRR are not = changed under your method. In my mind, the proposed solution is elegant and = works, but the elegance is 
not needed to solve this Class 3 error recovery = corner case for tapes.  I 
believe it preferable to preserve the Parameter = field in the frame header 
for more pervasive problems and for future = expansion.  The only thing necessary to solve this problem = is to be able to distinguish 
OX_ID A from OX_ID A'.  A single bit, think of = it as an extension of the 
OX_ID, is all that is necessary to make this = distinction.  The 
implementation (Initiator) would have to remember = the setting of this bit 
(lets call it Herman) on a per OX_ID basis and flip = Herman on the next usage 
of the  same OX_ID. Herman can be specified by Byte 1, Bit 7 in the = FCP_CMD IU, which is 
currently reserved. Herman can be specified in Byte 5, Bit 7 of the REC = Payload, which is 
currently reserved.  The REC is ACCed or = Rejected as a function of the 
presence of the OX_ID and the setting of Herman in = the Target (Initiator for 
the FCP Confirm case).  There is no need to = return Herman in the ACC/Reject 
Payload. 
  
Herman can be specified in byte 13, bit 7 of the SRR = Payload, which is 
currently reserved.  The SRR is ACCed or = Rejected as a function of the 
presence of the OX_ID and the setting of the bit in = the Target. There is no 
need to return Hermman in the ACC/Reject = Payload. I believe this solves the problem and should not = impact current 
implementations, assuming they are not checking = reserve fields or assuming 
that they are 0. REC will have to be changed in = FC_FS if it has already been 
incorporated.  Other changes would be contained = in FCP-2. 
Regards, Carl Carl Zeitler 
Compaq Computer Corporation 
MS 150801, 20555 SH249, Houston, TX 77070 
Phone:281-518-5258 Fax: 281-514-5270 
E-Mail: Carl.Zeitler at compaq.com 
------_=_NextPart_001_01BFDD21.D67FF012--




More information about the T10 mailing list