SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Home

Last updated: Wed Mar 27 23:18:13 2002
9359 messages in chronological order