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

["Julian Satran" <Julian_Satran@il.ibm.com>]

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
##################################