RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI: items discussed at WG meeting]]

["Dave Peterson" <dap@cisco.com>]

Again, 2nd try...

 

I am opposed to removing CRN support from iSCSI. Additional LU functionality (such as multi-pathing) can be achieved using a CRN. And as Julian indicates, there is not much work for the iSCSI protocol to support it. Any additional logic depends on the implementation.

 

There are rules for CRN processing. iSCSI currently does not provide enough text/reference for its use. I apologize if you feel consensus was reached previously.

But CRN behavior is still an issue for iSCSI, especially for bridging/gateway environments (which are extremely important at this point in the iSCSI evolution).

It has been mentioned that CRN is a SCSI ULP entity, as such it should be in the LU based Control mode page bit to indicate its usage. At this time there are

no proposals to add this functionality in T10. If the group believes this the correct approach, I will do the necessary legwork to make it happen (or not) in T10.

 

In reality, existing FCP-2 devices that support CRN implement this functionality at the FCP-2 initiator layer. This is equivalent to the iSCSI layer in my mind.

As such, the protocol specific LUN mode page works nicely. Yes it may waiver on the "layering" boundry, but so what. iSCSI is a mapping of SCSI.

 

Dave

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Thursday, March 28, 2002 2:47 AM
To: Santosh Rao
Cc: IPS Reflector; owner-ips@ece.cmu.edu
Subject: Re: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI: items discussed at WG meeting]]

I would say that CRN (wherever used) might add to the LU functionality and iSCSI can support it with no additional cost as we already support a stronger ordering.
Support involves only accepting the parameter and transporting it and no additional logic.

BTW are we going to constantly reopen issues on which we reached consensus a while ago without good reason for reopening!

Julo

Santosh Rao <santoshr@cup.hp.com> Sent by: owner-ips@ece.cmu.edu 28-03-02 05:05 Please respond to Santosh Rao

To:        IPS Reflector <ips@ece.cmu.edu>         cc:                 Subject:        iscsi: CRN support not required. [was :Re: [Fwd: iSCSI: items discussed  at WG meeting]]

Hello,

[ I changed the subject of this thread to be more meaningful to the
issue being discussed.]

Based on the below considerations, I am in favor of following the
example set by other serial scsi transports such as packetized SPI-x &
SRP, in not supporting CRN for iscsi.

Consider the following :

1) CRN is only defined as a parameter in SAM-2. Its usage semantics have
not been explained in SAM-2. It has also been made optional to support
for each scsi transport.

2) CRN usage description seems to have been left to each scsi transport,
based on the only usage being described in FCP-2, and not in SAM-2.

3) iscsi's CmdSN provides similar semantics as CRN, but at a session
granularity. (CmdSN usage, is mandatory, compared to an optional CRN.
CRN is on a per-lun basis. Cmdsn is 32-bit vs. 8-bit CRN.)

4) Due to mandatory use of CmdSN in iscsi, iscsi guarantees transport
ordering for command delivery and eliminates the need for yet another
sequencing scheme using CRN.
Other scsi transports that provide an ordered reliable transport do not
support CRN. The only scsi transport that supports CRN is FCP-2 and it
uses CRN to apply sequencing in a manner similar to iscsi using CmdSN.

Based on the above, I believe iscsi does not need to support CRN.

Comments ?

Thanks,
Santosh




http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03428.html


"Elliott, Robert" wrote:
>
> Comments below...
>
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Tuesday, March 26, 2002 7:50 PM
> > To: IPS Reflector
> > Subject: Re: [Fwd: iSCSI: items discussed at WG meeting]
> >
> > "Elliott, Robert" wrote:
> > >
> > > Don't assume that every new SCSI protocol will support CRN -
> > > SRP does not, for one.
> >
> > From a reading of SAM-2, it appears that the "Send SCSI Command" and
> > "SCSI Command Received" APIs (Section 5.4.2) define the CRN as one of
> > the arguments, which seems to imply that scsi transports should be
> > capable of transporting this argument, if the application
> > client decides to use it. (at least the newer scsi transports.)
> >
> > Are you saying that this is not the case ?
>
> Yes.
>
> > What is the basis for SRP not supporting CRN ?
>
> The description of CRN in SAM-2 mentions that protocols might not
> support it - "It is not an error for the application client to
> provide this argument when CRN is not supported by the SCSI protocol
> or logical unit."
>
> The same holds for autosense (although we did add language recently
> requiring all protocols except Parallel SCSI support autosense).
>
> > What are the guidelines that determine whether a scsi transport should
> > support CRN or not ?
>
> If the transport provides out of order delivery and you want to be able
> to send queued commands to tapes, CRN may be helpful.
>
> > If the CRN is not required to be supported by all scsi transports, is
> > there a reason that iscsi needs to support this ?
>
> Since iSCSI has added sequence numbers everywhere, CRN is not much of
> an extra burden.

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################