FCP_CONF/CRN

Dave Peterson dap at nsco.network.com
Fri Jul 31 07:51:55 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Dave Peterson <dap at nsco.network.com>
*

--------------3EA73809C896BD210F8ABE25
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The host takes no other action other than releasing the Exchange
after the FCP_CONF is sent. If the target
does not receive a FCP_CONF within FCP_TOV it sends an ABTS (check
status flavor) for the Exchange.
If a BA_RJT is returned the target knows the FCP_CONF was sent.
Missing is a text describing what the target shall do if a BA_ACC is returned.
In this case the initiator somehow has not yet sent the FCP_CONF, I would
propose the target keep waiting FCP_TOV and send ABTS (check status).

What more is needed to "model" FCP_CONF usage?


Bob Snively wrote:

> Rob,
>
> >
> > On the second point:
> > There are two reasons I can broadly see for using FCP_CONF:
> > 1. I want to change state - This needs definition as talked about in the first
> > point.
> >
> > 2. I want to free a resource (I know this is really a subset of change state)
> -
> > A statement to the effect that once FCP_CONF is received, the Target and LUN
> > may freely release all resources associated with the Exchange is all I need to
> > use this in any manner I see fit relative to resources I keep within the
> Target
> > and/or LUN relative to an Exchange.  I can think of two or three usages in
> > queueing and environments with large numbers of initiators.  Does the host
> > care?  No.  Do other target code implementations care?  It depends on what
> chip
> > set they have and their code structure, their data buffer sizes and the size
> of
> > their data structures to manage Exchanges.  Many tape devices would not need
> > FCP_CONF at all, and those that would will need it in slightly different
> > situations, although I think in a general sense it could be explained.
> >
>
> If the host does not care, then it will take no action when FCP_CONF
> occurs.
>
> If a target doesn't care, of course, it will not ask for it.
>
> Now the real problem is when a target does care and requests FCP_CONF.
> I would assume it did so because it wanted the host to do something
> special if FCP_CONF were not returned.  But if the host doesn't care, it
> will recognize communications about a missing FCP_CONF from the target
> as garbage and will take no actions, perhaps even thinking they are
> actions on behalf of some exchange of which the host is not aware.
>
> >From this, I presume that the host does care, and very much, what the
> target is going to expect as an FCP_CONF recovery action. If the host
> really is not supposed to care, then I can only presume the target didn't
> really care either and the FCP_CONF should not have been requested in
> the first place.
>
> Which is where I started.  You need a model to indicate why anyone cares and
> what is expected to be provided as part of that caring, or else it should
> not be standardized.
>
>   ------------------------------------------------------------------------
>
> Subject: RE: FCP_CONF/CRN
> Date: Tue, 28 Jul 1998 11:30:08 -0400
> From: Rob Basham <robbyb at us.ibm.com>
> To: <Bob.Snively at Ebay>
> CC: <ntw20 at netcom.com>, <Dale_lafollette at stortek.com>,
>      <Douglas.Hagerman at digital.com>, <dap at nsco.network.com>,
>      <charles.binford at symbios.com>, <roweber at symbios.com>
>
> Bob,
> Your points are well taken.  See my response below:
>
> On the first point:
>  I agree that there is no solid mechanism for alternate channel error
> reporting.  Why should a host try alternate port error recovery if it is going
> to work N different ways?  (The answer is, the big shops are willing to pay a
> premium so it will be worth my while even if it isn't standard).  One of the
> problems I have is that I'm pretty set in my ways on alternate port error
> recovery.  I don't want to start a grand project like Gary Stephens did years
> ago on this and for it to go nowhere.   If this were to happen, I would want it
> to happen as a group effort.
>
> If I can't get a group effort started on this, I will do my own vendor unique
> implementation like I have in SCSI today that I use as a differentiator.  That
> said, I would prefer to do it in a standard way.
>
> On the second point:
> There are two reasons I can broadly see for using FCP_CONF:
> 1. I want to change state - This needs definition as talked about in the first
> point.
>
> 2. I want to free a resource (I know this is really a subset of change state) -
> A statement to the effect that once FCP_CONF is received, the Target and LUN
> may freely release all resources associated with the Exchange is all I need to
> use this in any manner I see fit relative to resources I keep within the Target
> and/or LUN relative to an Exchange.  I can think of two or three usages in
> queueing and environments with large numbers of initiators.  Does the host
> care?  No.  Do other target code implementations care?  It depends on what chip
> set they have and their code structure, their data buffer sizes and the size of
> their data structures to manage Exchanges.  Many tape devices would not need
> FCP_CONF at all, and those that would will need it in slightly different
> situations, although I think in a general sense it could be explained.
>
> Regards,
> Rob
>
> In response to your first point, SCSI does not have a concept of an
> affiliated channel.  As a result, even correct sense information from
> an alternate channel is not known to be related to a state caused by
> a sequence of events on a primary channel.  There is no rule that says
> that an operation from an alternate channel will pick up sense
> information saved on behalf of a primary channel.  Alternate port recovery is
> not going to be able to seamlessly pick up where the previous port
> left off unless the tape and/or application is well-behaved and
> has a concept of locate or block labeling that is independent of the
> sequence of events on the previous port.  I have been pushing uselessly
> for such proper tape behavior for years, and have always been told that
> tapes are special and cannot have such behavior.  Seamless stateful
> affilitated channel is not a SCSI concept.
>
> In response to your second point, I cannot see how you can implement
> a profile compliant driver without understanding precisely the
> behavior expected from a profile compliant target.  That includes when
> and why it will generate FCP_CONF and what range of behaviors should
> be invoked by target and initiator upon receiving or failing to
> receive FCP_CONF.  If there is no such explicit understanding,
> it cannot realistically be part of a profile and should be removed.
> I would hope that the FCP-2 document would be held to similar standards.
>
> Bob
>
> ------------- Begin Included Message -------------
>
> To: <T10 at Symbios.COM>
> Subject: Re: FCP_CONF/CRN
> Date: Mon, 27 Jul 1998 12:00:46 -0400
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
> * Rob Basham <robbyb at us.ibm.com>
> *
>
> Two points on this topic from a different point of view:
>
> 1.  Unlike in Parallel SCSI, I believe that Dual Ported tape drives in Fibre
> Channel will be common.  I also believe that Auto-Sense will be common.
>
> FCP_CONF is useful in cases of complete failure on one link where some attempt
> is going to be made at the ULP to use an alternate port to the device.  It
> allows the LUN to know that sense data was not successfully sent up on one port
> and to send the error data again via the other port.  In the case of complete
> port failure, neither ACA nor the low-level ELS's will help with getting sense
> data properly reported.
>
> The most difficult time is not when writing, which is when Recover Buffered
> Data is useful and could help.  The most dangerous time for alternate port
> error recovery is when reading and a BLOCK SEQUENCE or POSITIONING type error
> is being reported.  In that case, the Recover Buffered Data scheme is of no
> help in alternate port error recovery.  It is while reading/spacing/locating
> that I really need FCP_CONF.  FCP_CONF is helpful in some cases when writing,
> but Bob is correct in that generally Recover Buffered Data would be adequate.
>
> Without FCP_CONF, in the case of alternate port error recovery we would need to
> devise some vendor unique way to close all the data integrity holes associated
> with SEQUENCE type errors, END OF DATA TRAVERSED, etc.  We will strongly
> discourage those who don't support FCP_CONF from doing alternate port error
> recovery.
>
> 3..  The specification doesn't provide all the proper uses in a tape drive for
> all functions.  For example, nowhere is it described why we have a Read command
> for tape drives.  Tools are provided and folks decide what clever way they want
> to leverage those tools.  I don't believe I need to give all the uses I have as
> a tape device for FCP_CONF.  Suffice it to say, I believe it has value in other
> situations like robust queueing, internal state changes, etc. and we intend to
> use FCP_CONF even when low-level error recovery is active and Recover Buffered
> Data is supported.  The only case where FCP_CONF is not needed is when class 2
> is supported, since the ACK can be leveraged for the same purposes.
>
> Rob Basham



--
===================================================================
Dave Peterson                     phone : 612-391-1008
Senior Engineer
StorageTek Network Systems Group  email: dap at network.com



--------------3EA73809C896BD210F8ABE25
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


 The host takes no other action other than releasing the Exchange 
after the FCP_CONF is sent. If the target 
does not receive a FCP_CONF within FCP_TOV it sends an ABTS (check 
status flavor) for the Exchange. 
If a BA_RJT is returned the target knows the FCP_CONF was sent. 
Missing is a text describing what the target shall do if a BA_ACC is returned. 
In this case the initiator somehow has not yet sent the FCP_CONF, I would 
propose the target keep waiting FCP_TOV and send ABTS (check status). What more is needed to "model" FCP_CONF usage? 
  Bob Snively wrote: Rob, > 
> On the second point: 
> There are two reasons I can broadly see for using FCP_CONF: 
> 1. I want to change state - This needs definition as talked about in the first 
> point. 
> 
> 2. I want to free a resource (I know this is really a subset of change state) 
- 
> A statement to the effect that once FCP_CONF is received, the Target and LUN 
> may freely release all resources associated with the Exchange is all I need to 
> use this in any manner I see fit relative to resources I keep within the 
Target 
> and/or LUN relative to an Exchange.  I can think of two or three usages in 
> queueing and environments with large numbers of initiators.  Does the host 
> care?  No.  Do other target code implementations care?  It depends on what 
chip 
> set they have and their code structure, their data buffer sizes and the size 
of 
> their data structures to manage Exchanges.  Many tape devices would not need 
> FCP_CONF at all, and those that would will need it in slightly different 
> situations, although I think in a general sense it could be explained. 
> If the host does not care, then it will take no action when FCP_CONF 
occurs. If a target doesn't care, of course, it will not ask for it. Now the real problem is when a target does care and requests FCP_CONF. 
I would assume it did so because it wanted the host to do something 
special if FCP_CONF were not returned.  But if the host doesn't care, it 
will recognize communications about a missing FCP_CONF from the target 
as garbage and will take no actions, perhaps even thinking they are 
actions on behalf of some exchange of which the host is not aware. >From this, I presume that the host does care, and very much, what the 
target is going to expect as an FCP_CONF recovery action. If the host 
really is not supposed to care, then I can only presume the target didn't 
really care either and the FCP_CONF should not have been requested in 
the first place. Which is where I started.  You need a model to indicate why anyone cares and 
what is expected to be provided as part of that caring, or else it should 
not be standardized.   ------------------------------------------------------------------------ Subject: RE: FCP_CONF/CRN 
Date: Tue, 28 Jul 1998 11:30:08 -0400 
From: Rob Basham <robbyb at us.ibm.com> 
To: <Bob.Snively at Ebay> 
CC: <ntw20 at netcom.com>, <Dale_lafollette at stortek.com>, 
     <Douglas.Hagerman at digital.com>, <dap at nsco.network.com>, 
     <charles.binford at symbios.com>, <roweber at symbios.com> Bob, 
Your points are well taken.  See my response below: On the first point: 
 I agree that there is no solid mechanism for alternate channel error 
reporting.  Why should a host try alternate port error recovery if it is going 
to work N different ways?  (The answer is, the big shops are willing to pay a 
premium so it will be worth my while even if it isn't standard).  One of the 
problems I have is that I'm pretty set in my ways on alternate port error 
recovery.  I don't want to start a grand project like Gary Stephens did years 
ago on this and for it to go nowhere.   If this were to happen, I would want it 
to happen as a group effort. If I can't get a group effort started on this, I will do my own vendor unique 
implementation like I have in SCSI today that I use as a differentiator.  That 
said, I would prefer to do it in a standard way. On the second point: 
There are two reasons I can broadly see for using FCP_CONF: 
1. I want to change state - This needs definition as talked about in the first 
point. 2. I want to free a resource (I know this is really a subset of change state) - 
A statement to the effect that once FCP_CONF is received, the Target and LUN 
may freely release all resources associated with the Exchange is all I need to 
use this in any manner I see fit relative to resources I keep within the Target 
and/or LUN relative to an Exchange.  I can think of two or three usages in 
queueing and environments with large numbers of initiators.  Does the host 
care?  No.  Do other target code implementations care?  It depends on what chip 
set they have and their code structure, their data buffer sizes and the size of 
their data structures to manage Exchanges.  Many tape devices would not need 
FCP_CONF at all, and those that would will need it in slightly different 
situations, although I think in a general sense it could be explained. Regards, 
Rob In response to your first point, SCSI does not have a concept of an 
affiliated channel.  As a result, even correct sense information from 
an alternate channel is not known to be related to a state caused by 
a sequence of events on a primary channel.  There is no rule that says 
that an operation from an alternate channel will pick up sense 
information saved on behalf of a primary channel.  Alternate port recovery is 
not going to be able to seamlessly pick up where the previous port 
left off unless the tape and/or application is well-behaved and 
has a concept of locate or block labeling that is independent of the 
sequence of events on the previous port.  I have been pushing uselessly 
for such proper tape behavior for years, and have always been told that 
tapes are special and cannot have such behavior.  Seamless stateful 
affilitated channel is not a SCSI concept. In response to your second point, I cannot see how you can implement 
a profile compliant driver without understanding precisely the 
behavior expected from a profile compliant target.  That includes when 
and why it will generate FCP_CONF and what range of behaviors should 
be invoked by target and initiator upon receiving or failing to 
receive FCP_CONF.  If there is no such explicit understanding, 
it cannot realistically be part of a profile and should be removed. 
I would hope that the FCP-2 document would be held to similar standards. Bob ------------- Begin Included Message ------------- To: <T10 at Symbios.COM> 
Subject: Re: FCP_CONF/CRN 
Date: Mon, 27 Jul 1998 12:00:46 -0400 
MIME-Version: 1.0 
Content-Transfer-Encoding: quoted-printable 
Content-Disposition: inline * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by: 
* Rob Basham <robbyb at us.ibm.com> 
* Two points on this topic from a different point of view: 1.  Unlike in Parallel SCSI, I believe that Dual Ported tape drives in Fibre 
Channel will be common.  I also believe that Auto-Sense will be common. FCP_CONF is useful in cases of complete failure on one link where some attempt 
is going to be made at the ULP to use an alternate port to the device.  It 
allows the LUN to know that sense data was not successfully sent up on one port 
and to send the error data again via the other port.  In the case of complete 
port failure, neither ACA nor the low-level ELS's will help with getting sense 
data properly reported. The most difficult time is not when writing, which is when Recover Buffered 
Data is useful and could help.  The most dangerous time for alternate port 
error recovery is when reading and a BLOCK SEQUENCE or POSITIONING type error 
is being reported.  In that case, the Recover Buffered Data scheme is of no 
help in alternate port error recovery.  It is while reading/spacing/locating 
that I really need FCP_CONF.  FCP_CONF is helpful in some cases when writing, 
but Bob is correct in that generally Recover Buffered Data would be adequate. Without FCP_CONF, in the case of alternate port error recovery we would need to 
devise some vendor unique way to close all the data integrity holes associated 
with SEQUENCE type errors, END OF DATA TRAVERSED, etc.  We will strongly 
discourage those who don't support FCP_CONF from doing alternate port error 
recovery. 3..  The specification doesn't provide all the proper uses in a tape drive for 
all functions.  For example, nowhere is it described why we have a Read command 
for tape drives.  Tools are provided and folks decide what clever way they want 
to leverage those tools.  I don't believe I need to give all the uses I have as 
a tape device for FCP_CONF.  Suffice it to say, I believe it has value in other 
situations like robust queueing, internal state changes, etc. and we intend to 
use FCP_CONF even when low-level error recovery is active and Recover Buffered 
Data is supported.  The only case where FCP_CONF is not needed is when class 2 
is supported, since the ACK can be leveraged for the same purposes. Rob Basham   -- 
===================================================================
Dave Peterson                     phone : 612-391-1008
Senior Engineer 
StorageTek Network Systems Group  email: dap at network.com  

--------------3EA73809C896BD210F8ABE25--

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list