Please review: Preliminary discussion of CRN approaches

[Robert Snively]

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at Brocade.COM>
*

Well, some of the information is in.  I am not counting votes yet (we will
do that at the FCP-2 meeting in Seattle), but I am filling out benefits
of each approach.  I am attributing these views as best I can. Note that
the rigorous ordering of awaiting command complete status is the presently
accepted mechanism for managing ordering, so that present day drivers 
do not require either type of CRN.  All of these discussions reference future
implementations (or in some cases, implementations in late stages of development).

Please review these, fill in the holes, and get your views on the reflector

A)  Considerations on using CRN per target

    1)  Overview

	The implicit assumption is that by assuring the ordering of each
	command operation on an I_T nexus, the delivery to the logical unit
	will necessarily be correctly ordered.  To do this, a CRN on an
	I_T nexus basis would be appropriate. (Wakeley, 7/11)

    2)  Benefits of using CRN per target

	a)  Driver independence

		At present, there are no drivers that have any knowledge of
		CRN functionality.  Using CRN on an I_T nexus basis would
		allow the HBA to enforce ordering at a low level, without
		the awareness of the driver and without the requirement to
		rewrite the higher drivers for FC CRN use. (Wakeley, 7/11)

	b)  Interface independence

		At present, all the drivers for other interfaces do not create
		an explicit indication of ordering for commands.  Since there
		is no architectural support for CRN in any of the other
		SCSI technologies, it is unlikely that FC CRN drivers will be
		created except for very special cases.  (Wakeley, 7/11)

    3)  Problems of using CRN per target

	a)  Stalling of unaffected logical units

		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. (Snively, 7/18)

	b)  Error recovery bypass of ordering

		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. (Snively, 7/18)

	c)  Task management an exception for the I_T nexus

		Task management must still be outside the CRN structure in order
		to perform some of the recovery mechanisms.  (Snively, 7/18)

	d)  Requirement to support both ordered and non-ordered on same target

		Bridge devices attach disk drives (no ordering requirements) and
		tape drives (ordering requirements) behind a single target.  Forcing
		them to both support target oriented CRNs is inappropriate. 
		(Baldwin, 7/18)

		Note that this may be addressable by using the task ordering
		attributes to automatically include or exclude individual 
		commands from the ordering process (Snively, 7/19)

	e)  No protection for ordering problems outside the FC fabric.

		Some queue structures historically used in HBAs and in 
		targets do not enforce ordering.  The result is that the
		application's ordering requirements may be subverted by either
		the driver to HBA queuing or by the target to logical unit
		queuing.  Note that more modern implementations may have
		cured all cases of this. (Snively, 7/19)

B)  Considerations on using CRN per LUN

    1)  Overview

	The explicit assumption is that any application that cares about enforcing
	ordering will provide ordering information that will be transported to the
	only natural destination of an application request, the logical unit.
	Logical units or operations that do not require such rigorous 
	verification of ordering will operate with the loose ordering 
	presently assumed for FC fabrics. (FCP-2r4)

    2)  Benefits of using CRN per LUN

	a)  Explicit low-level management of ordering

		Ordering can be applied as required for those logical units that 
		require it. (FCP-2r4, Baldwin 7/18)

	b)  Ordering protected across queue boundaries

		The desired ordering of commands from an application to a 
		logical unit is preserved independent of queuing issues 
		associated with application to driver queues, driver to
		HBA queues, fabric re-ordering, and target to logical unit queues.
		(Snively 7/19)

    3)  Problems of using CRN per LUN

	a)  No drivers are available to pass CRN through to a logical unit.
		(general)

	b)  Drivers will require FC specific capabilities to use CRN anyway.
		(Baldwin 7/18)


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

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