FC-TAPE Command Reference Numbers
Dave.Baldwin at emulex.com
Thu Oct 29 15:22:55 PST 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Baldwin, Dave" <Dave.Baldwin at emulex.com>
PLEASE put the PRLI CRNS bit back in to the FCP-2 document. We have =
discussed this issue previously in the FC-TAPE working group, and the =
decision was to provide this feature.
Some companies have control over all pieces of the operating systems =
they have to deal with, so your proposal would make sense in these =
Other companies, like mine, need to provide HBA device drivers that run =
on several different operating systems. We do not have a lot of =
influence over operating system vendors, and can't get them to put the =
necessary changes in required by your implementation. Some still can't =
support more than 16 targets per adapter board, or more than 8 LUNs per =
target, which for us would be a higher priority than implementing the =
ECRN functionality. We don't have several years before we need this =
behavior, we need it now.
HBA drivers are not supposed to be doing MODE SENSE/SELECT commands, and =
doing so would be very distasteful. Using the CRNS bit to determine =
whether the HBA driver provides a CRN in the FCP_CMD is a very simple =
and very useful mechanism. Please reconsider your decision.
Emulex Network Systems
From: Bob Snively
Sent: Thursday, October 29, 1998 10:44 AM
To: fc at nsco.network.com; t10 at symbios.com
Subject: FC-TAPE Command Reference Numbers
While working on the FCP-2 document, I thought long and carefully about
how we use CRN. I have made the following adjustments in the first =
of FCP-2. I hope everybody likes them.
1) Naming the function
I have arbitrarily named the function provided by CRN as "precise =
2) Determination and enabling
At present, the FC-TAPE document has two independent mechanisms for
determining the support of precise ordering:
a) Process Login negotiates the support of precise ordering using
the CRNS (CRN supported) bit.
b) The FC Control mode page controls the enabling of precise
ordering using the ECRN bit.
Because of the splendors of the SCSI implementation, this dual enabling
is actually redundant.
The precise ordering function is actually a function that is decided =
and required on a command by command basis for a certain class of =
As such, it is really a SCSI level functionality, not a Fibre Channel =
functionality. And the SCSI level control function, provided by=20
MODE SENSE/SELECT, is sufficient to properly identify, control, and
enable precise ordering.
Therefore I propose to drop the PRLI CRNS bit.
What remains is the ECRN bit managed by MODE SENSE/SELECT.
Each initiator can talk to its own applications in a vendor specific =
to let the application client know that it supports precise ordering. =
this is necessary anyway, since the application client must be capable =
instructing the initiator which commands should have precise ordering=20
applied. The application client then asks the device server of the =
whether or not the precise ordering capability is supported using the
appropriate MODE SENSE command. If there is pre-knowledge, it may be
sufficient to ask if the current ECRN bit is one, indicating not only =
it is capable of precise ordering, but presently executing it. If there =
no pre-knowledge, the bomb-proof mechanism is to ask the device server =
the ECRN bit is changeable. If it is, the application client can choose =
set it or clear it. If it is not, the application client knows that the
function is not supported.
That all provides a clean, fool-proof, SCSI only mechanism, making the
PRLI CRNS an unnecessary request across some strange architectural =
Bob Snively Phone: (510) 574-9051
Sun Microsystems Computer Company =20
Mail Stop NWK 04-104
901 San Antonio Road E-mail: bob.snively at sun.com
Palo Alto, CA 94303
* 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