FCP-2: Reasons why CRN must be target based (not lun based)

Wed Jul 19 07:10:56 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_01BFF18B.2A21063E
Content-Type: text/plain; charset="iso-8859-1"

In Dave's recent email he said the following:

"Once the target's queue fills up, it can't even return queue fulls
because the commands need to execute in order. The only alternative is
to drop further commands on the floor."

FCP-2 rev 4 says:

"The device server shall not accept a command with a nonzero CRN into
its execution queue until all commands with a previous CRN have been
received by the device server."

So the question is a target allowed to return queue full on a command
with CRN if it has not yet completed the previous commands?  I have
always thought that a target could return queue full without "accepting
a command .... in to its execution queue..".  

While we're here, what about BUSY, RESERVATION CONFLICT, my new TASK
ABORTED?????

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

> -----Original Message-----
> From: Baldwin, Dave [ mailto:Dave.Baldwin at emulex.com
 ]
> Sent: Tuesday, July 18, 2000 6:12 PM
> To: Matt Wakeley
> Cc: Robert Snively; t10 at t10.org; fc at network.com
> Subject: Re: FCP-2: Reasons why CRN must be target based (not
> lun based)
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Baldwin, Dave" <Dave.Baldwin at emulex.com>
> *
> Matt,
>
> Command frames should not be dropped often, but they will be
> dropped occasionally. When a command is dropped, every command to the
target would have to
> be held up by the target until it can figure out what LUN the command
was destined for. Your
> suggestion of a new ELS would make this happen quicker, but even with
this addition, if the
> ELS handling is done in the device driver, it could take 100s of
milliseconds.
>
> Once the target's queue fills up, it can't even return queue fulls
because the commands need to execute in order. The only alternative is
to drop further commands on the floor. This causes even bigger recovery
problems, now on multiple LUNs.
> It looks very ugly to me...
>
> FC to SCSI bridges will feel the pain, as all the SCSI
> devices are treated as LUNs from the Fibre Channel Initiator's
perspective. The FCP-2 retry bit is
> defined in the PRLI command which applies to all the LUNs behind an
N_Port. I'm also
> sure there are multi-LUN tape devices being developed. There may be
multi-LUN tape/disk
> devices being developed (although if I were doing the development I
would put the tape and disk
> devices on separate D_IDs).
>
> If any OS vendors bite off on the task of implementing queued
> tape commands (which I don't see happening soon), the least of their
worries would be putting
> in CRN. The error recovery is extremely complex. Passing the CRN in a
structure down to the
> HBA driver level is a trivial task. If a customer is OK with running
parallel SCSI, then
> they don't need to even run FCP-2. Just recover commands on an
exchange basis in Fibre Channel
> and you get the same behavior. I believe any OS vendor that takes the
effort to implement
> queued tape commands would also see the benefit in supplying a CRN for
FCP-2 recovery.
>
> Best regards,
> Dave Baldwin
> 

------_=_NextPart_001_01BFF18B.2A21063E
Content-Type: text/html; charset="iso-8859-1"

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

In Dave's recent email he said the following:

 "Once the target's queue fills up, it can't even return queue fulls because the commands need to execute in order. The only alternative is to drop further commands on the floor."

 FCP-2 rev 4 says:

 "The device server shall not accept a command with a nonzero CRN into its execution queue until all commands with a previous CRN have been received by the device server."

 So the question is a target allowed to return queue full on a command with CRN if it has not yet completed the previous commands?  I have always thought that a target could return queue full without "accepting a command .... in to its execution queue..".  

 While we're here, what about BUSY, RESERVATION CONFLICT, my new TASK ABORTED?????

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

> -----Original Message-----
> From: Baldwin, Dave [mailto:Dave.Baldwin at emulex.com]
> Sent: Tuesday, July 18, 2000 6:12 PM
> To: Matt Wakeley
> Cc: Robert Snively; t10 at t10.org; fc at network.com
> Subject: Re: FCP-2: Reasons why CRN must be target based (not
> lun based)
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Baldwin, Dave" <Dave.Baldwin at emulex.com>
> *
> Matt,
>
> Command frames should not be dropped often, but they will be
> dropped occasionally. When a command is dropped, every command to the target would have to
> be held up by the target until it can figure out what LUN the command was destined for. Your
> suggestion of a new ELS would make this happen quicker, but even with this addition, if the
> ELS handling is done in the device driver, it could take 100s of milliseconds.
>
> Once the target's queue fills up, it can't even return queue fulls because the commands need to execute in order. The only alternative is to drop further commands on the floor. This causes even bigger recovery problems, now on multiple LUNs.
> It looks very ugly to me...
>
> FC to SCSI bridges will feel the pain, as all the SCSI
> devices are treated as LUNs from the Fibre Channel Initiator's perspective. The FCP-2 retry bit is
> defined in the PRLI command which applies to all the LUNs behind an  N_Port. I'm also
> sure there are multi-LUN tape devices being developed. There may be multi-LUN tape/disk
> devices being developed (although if I were doing the development I would put the tape and disk
> devices on separate D_IDs).
>
> If any OS vendors bite off on the task of implementing queued
> tape commands (which I don't see happening soon), the least of their worries would be putting
> in CRN. The error recovery is extremely complex. Passing the CRN in a structure down to the
> HBA driver level is a trivial task. If a customer is OK with running parallel SCSI, then
> they don't need to even run FCP-2. Just recover commands on an exchange basis in Fibre Channel
> and you get the same behavior. I believe any OS vendor that takes the effort to implement
> queued tape commands would also see the benefit in supplying a CRN for FCP-2 recovery.
>
> Best regards,
> Dave Baldwin
> 

------_=_NextPart_001_01BFF18B.2A21063E--