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

[Robert Snively]

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at Brocade.COM>
*
All right everybody,  what do you think?

The principal valid point here is that "nobody else uses CRNs 
based on logical unit, so it won't be supported".

The concerns here include:

	1)  A failing or missing command for one logical unit stalls
		all logical units, even those doing unrelated tasks
		managed by a different driver, until the failing one is recovered.

	2)  The error recovery driver must selectively disable CRNs
		(I assume by posting a 0 value) to sneak stuff by the blockade
		to complete the recovery for a logical unit.

	3)  Task management must still be outside the CRN structure in order
		to perform some of the recovery mechanisms.

	4)  Probably others not yet studied.

Either we shoot this down, which means that FCP drivers have an additional
ordered queuing capability and requirement, or we embrace it, which means
we have to install corrections or recognition to all the concerns above
plus all the others we find.

A)  Which will it be, target oriented CRNs or LUN oriented CRNS?

B)  If target oriented CRNS, what must we do to address the identified
	concerns and what other concerns must be resolved?

Bob Snively
Brocade Communications           Phone  408 487 8135
1901 Guadalupe Parkway
San Jose, CA 95131               Email   rsnively at brocade.com



>  -----Original Message-----
>  From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
>  Sent: Tuesday, July 11, 2000 1:26 AM
>  To: t10 at t10.org; fc at network.com
>  Subject: FCP-2: Reasons why CRN must be target based (not lun based)
>  
>  
>  *
>  * From the fc reflector, posted by:
>  * "Matt Wakeley" <matt_wakeley at agilent.com>
>  *
>  In the T11.3/T10 meeting on 7/10, there was a (long) 
>  discussion on whether the
>  CRN (command reference number - better defined as the CON, 
>  command order
>  number) should be based on a per LU basis or a target basis. 
>   I argued that it
>  should be on a per target basis because FCP-2 really defines 
>  the behavior of
>  the Fibre Channel SCSI Delivery Subsystem.  The SDP (SCSI 
>  Delivery Port) on
>  the initiator and the SDP on the target work together to 
>  guarantee that the
>  commands submitted to the initiator SDP are delivered from 
>  the target SDP in
>  the same order they were submitted to the initiator SDP.
>  
>  CRN on a target basis requires that the initiator SDP 
>  maintain a CRN counter
>  on a per target basis that is incremented when any command 
>  is delivered to the
>  target.  The SDP already has data structures on a per target 
>  basis anyway to
>  store items such as the Node ID, and login information.  So 
>  it is not much
>  extra overhead for the SDP to maintain this CRN counter on a 
>  per target basis.
>  
>  CRN on a LU basis requires that some entity maintain the CRN 
>  on a LU basis per
>  target.  Now, (in a properly layered model) the SDP does not 
>  know anything
>  about how many LUs there are in a target, and how those LUs 
>  are assigned
>  numbers (LUNs).  The LU information is gathered and 
>  maintained by the upper
>  level SCSI (class) driver and/or the application. This means 
>  that if the
>  initiator SDP is to maintain the CRNs on a per LU basis, it 
>  must maintain 2^64
>  CRNs per target (since the LUN field is 64 bits). (I reject 
>  the arguments that
>  the FCP-2 SDP duplicate the discover LUNs functions that are 
>  already performed
>  by the upper layers - that's why I said "properly layered".)
>  
>  The argument was that the SDP does not have to maintain this 
>  large table
>  because the SCSI (class) driver and/or application will pass 
>  the value to the
>  SDP as part of the parameters of CDB.
>  
>  I pointed out that currently in NT there is no way for the 
>  application to pass
>  this CRN through the MS SCSI class driver, and the MS SCSI 
>  class driver
>  certainly does not maintain a CRN.
>  
>  The argument against this was that there currently are not 
>  any "queuing"
>  applications that run on NT that require command ordering, 
>  so who cares about
>  CRN in the NT environment. And that when/if there are, the 
>  applications will
>  be written to maintain the CRN, and MS will modify the SCSI 
>  class driver to
>  enable passing the CRN to the SDP.
>  
>  Well, my response to that is that suppose someone did write 
>  a "queuing"
>  application on NT that requires command ordering.  If the 
>  application is run
>  on a system using a SCSI parallel bus, the application 
>  doesn't need to
>  maintain a CRN, since "errors don't occur on the SCSI 
>  parallel bus" and
>  commands will always be delivered in order.  If the 
>  application is run on a
>  system using the "SCSI over VI" transport, the application 
>  doesn't need to
>  maintain a CRN because the VI environment will deliver 
>  messages in order.  If
>  the application is run on a system using the proposed "SCSI over IP"
>  transport, the application doesn't need to maintain a CRN 
>  because that
>  transport will also deliver commands in the order they are 
>  passed down the
>  stack.
>  
>  *BUT* if this application is run on a system using Fibre 
>  Channel, all of a
>  sudden the application is required to maintain a CRN value 
>  on a per LU basis,
>  because FCP at the SDP layer is unable to deliver commands 
>  from the SDP layer
>  to the LUs in the order they were passed to the SDP layer on 
>  the initiator
>  side.  This certainly doesn't make applications portable to 
>  Fibre Channel.
>  Also, since FCP-2 is now mandating that the LU is to 
>  maintain this ordering,
>  it forces a change to SAM-2 to define to the command 
>  reference number as a
>  parameter to the LU.
>  
>  Therefore, I still maintain my argument that FCP-2 *MUST* 
>  implement the CRN on
>  a per target basis so that FCP-2 (which implements the SAM-2 
>  SDP) can deliver
>  commands up from the target SDP to the LUs in the same order 
>  they were
>  submitted down to the initiator SDP.
>  
>  Matt Wakeley
>  Agilent Technologies
>  
>  
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org