FCP-2 recovery problem

Zeitler, Carl Carl.Zeitler at COMPAQ.com
Fri Jun 23 12:31:44 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
*
You are right.  Adding just one bit still leaves you with the same problem
twice removed.  

The extension of the CRN is a good idea.   If one byte is not big enough to
lower the wrap probabilities enough it could be increased to 2 or 4 bytes at
this point in time, hopefully with not too much tear-up of existing
implementations.

Your concept of mixing layers  is similar to my uneasy feelings of carrying
this information in the frame header.  So am in complete agreement with your
solution direction. 

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


-----Original Message-----
From: Binford, Charles [mailto:cbinford at lsil.com]
Sent: Friday, June 23, 2000 9:47 AM
To: T10 at t10.org; 'FC Reflector'
Subject: RE: FCP-2 recovery problem


*
* From the fc reflector, posted by:
* "Binford, Charles" <cbinford at lsil.com>
*
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--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list