Please review: Preliminary discussion of CRN approaches
Carl.Zeitler at COMPAQ.com
Thu Jul 20 04:52:46 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
See comments interspersed below.
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
From: Robert Snively [mailto:rsnively at Brocade.COM]
Sent: Wednesday, July 19, 2000 2:52 PM
To: t10 at t10.org; fc at network.com
Subject: Please review: Preliminary discussion of CRN approaches
* From the fc reflector, 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
implementations (or in some cases, implementations in late stages of
Please review these, fill in the holes, and get your views on the reflector
A) Considerations on using CRN per target
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
an explicit indication of ordering for commands. Since
is no architectural support for CRN in any of the other
SCSI technologies, it is unlikely that FC CRN drivers will
created except for very special cases. (Wakeley, 7/11)
**I fully agree with Mattt. Furthermore, SCSI over VI over IB and SCSI over
TCP/IP will not require special ordering. So that leaves Fibre Channel with
this unique ordering requirement at the application level. Chances of our
favorite OS's changing to meet a unique FC requirement are slim to none.
Such a requirement will put us at a competitive disadvantage.
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)
**Right or wrong, I've always believed that performance in error situations
is not a priority, data integrity is. If the link is lousy, performance
will be abysmal to worse, regardless of LUN or Target CRN orientation. The
same holds true for congestion situations, but the argument is a little
weaker, i.e., frames get tossed in class 3 and busied and retransmitted in
Class 2. Again your on the brink of or over the cliff and are in need of
some reconfiguration to really solve the problem. Otherwise you are just
putting balm on the effects.
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
to complete the recovery for a logical unit. (Snively, 7/18)
**The use of CRN=0 is necessary for recovery, regardless of LUN or Target
orientation. I don't see the difference.
c) Task management an exception for the I_T nexus
Task management must still be outside the CRN structure in
to perform some of the recovery mechanisms. (Snively, 7/18)
**Correct, regardless of CRN orientation.
d) Requirement to support both ordered and non-ordered on same
Bridge devices attach disk drives (no ordering requirements)
tape drives (ordering requirements) behind a single target.
them to both support target oriented CRNs is inappropriate.
**Anyone who mixes data intensive tape and transaction oriented discs on the
same interface deserves what he gets, hopefully an education that you don't
mix the sheep and the goats, or you don't care about performance and cost is
overriding. But again it is only in error situations where you get this
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
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
The explicit assumption is that any application that cares about
ordering will provide ordering information that will be transported
only natural destination of an application request, the logical
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
require it. (FCP-2r4, Baldwin 7/18)
**See A) 2) b) comment above.
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
**See A) 2) b) comment above.
3) Problems of using CRN per LUN
a) No drivers are available to pass CRN through to a logical unit.
b) Drivers will require FC specific capabilities to use CRN anyway.
**I see no motivation to do this in the future.
**In summary I vote with Matt to use CRN on a Target basis.
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
More information about the T10