SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI : login keys & mode page settings



    
    
    Santosh,
    
    answers in text.
    
    And again - please tone down your notes.
    
    Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 19/04/2001 18:59:36
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
    cc:   Stephen Bailey <steph@cs.uchicago.edu>, David Black
          <Black_David@emc.com>
    Subject:  Re: iSCSI : login keys & mode page settings
    
    
    
    
    Stephen Bailey wrote:
    >
    > > +++ It is all about function - several people felt that the (primitive)
    > > negotiation element in the text commands is better than trying to set a
    > > parameter to an unacceptable value and finding this out through a mode
    > > sense
    > > ++++
    >
    > Several other people seem to have felt that it was better not to have
    > redundant mechanisms for manipulating this sort of parameter.  How do
    > you decide?
    >
    > Steph
    
    
    Julian,
    
    I would prefer a single mechanism as opposed to multiple redundant
    mechanisms to set negotiation elements. (Reduce/eliminate options.). In
    addition, I have the following concerns [some of which I have raised
    repeatedly and have NOT gotten a reply. I would appreciate if you could
    kindly comment on ALL of these.] :
    
    +++ I will if you will stop SCREAMING. And rememember that I am not bound
    to by any rules other than respect for the individual +++
    
    1) The draft makes repeated references to a "iSCSI LUN Control Mode
    Page". There is NO such page per SPC-2. The references must be changed
    to "iSCSI protocol specific LUN page".
    
    +++ it is called iSCSI LU control mode page the same way as FCP call it.
    And this is one of those instances in which the tone of your note is
    irritating to say the least.
    +++
    
    2) The new daily release of the draft (5.92 when I last checked) has now
    introduced EnableACA as a negotiable login key. All references to
    EnableACA are redundant and should be removed for the following reasons
    :
    
    a) An initiator knows whether a target supports ACA from the NACA bit in
    the INQUIRY response. When a target indicates support for ACA, the
    initiator can use it by setting the NACA bit in the CDBs it sends. There
    is NO need for any sort of negotiation of this behaviour above and
    beyond what is already provided thru SCSI mechanisms.
    
    b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating its
    use or lack thereof. This is done thru the NACA bit in CDBs.
    
    c) (As a side note, the description of EnableACA on pg 127 refers to its
    presence in the lun control mode page, but it is actually present in the
    protocol specific port page.)
    
    d) ACA is a LUN-level (more an I/O level) control option. It MUST NOT be
    negotiated on a per-session basis. SCSI allows initiators to request ACA
    behaviour on a per I/O basis through the use of NACA bit in the CDBs.
    
    +++ We have required ACA to be supported by all new iSCSI targets and
    several
    actions require the target to enter ACA state.
    It was brought to our attention that many initiators will not react
    properly to a
    target entering ACA state (not do the reset).
    The EnableACA bit and key are meant to enable an initiator to control this
    iSCSI specific ACA behaviour.  This behaviour is related to asynchronous
    events and is not controlled by the NACA CDB bit.
    
    ++++
    
    
    2)
    > On a side note, the EnableCmdRN  & CmdRN fields should be re-named to
    > EnableCRN and CRN to reflect the same semantics and context as the CRN
    > defined in SAM-2 and FCP-2.
    >
    > +++ what's in a name... +++
    
    Consistency for one ! (Any strong reasons not to call this CRN, as SAM
    and FCP do ?)
    
    +++ No strong reason except the fact that iSCSI - has its own naming style
    - but I've changed
    this.
    +++
    
    3) However, having allowed 2 mechanisms to set negotiation elements,
    iSCSI MUST
    then comment on the need to synchronize their settings in the 2 layers
    and also comment on the need to trigger a UNIT ATTENTION when changed
    through the login key mechanism.
    Again, I would vote for only 1 mechanism for setting these control
    options, rather than have to define communication schemes b/n the ULP
    and LLP to keep their values in synch and generate UNIT ATTENTION.
    
    +++ Parameter changes originate from SCSI and iSCSI only enables another
    mechanism to convey them.
    This is an implementation issue +++
    
    4)
    > If such a level of dual control is provided, the iSCSI login
    > keys listed above be made LO (leading only) to allow for changes to
    > operational parameters only during session login. This is to
    > minimize/eliminate disruption of ongoing I/O activity that occurs due to
    > the generation of a UNIT ATTENTION CHECK CONDITION when any change is
    > made to the above paramters.
    
    Are we in agreement on the above ?
    
    +++ No +++
    5)
    > If these operational parameters are allowed to be set through iSCSI
    > login and they also impact mode page settings, iSCSI spec should
    > describe the scope of the mode page setting in terms of whether this
    > setting is a saved page setting or not ?
    >
    +++ I don't know - I would rather think not +++
    6)
    > Should saved page settings be allowed thru iSCSI ?
    +++ I don't know - I would rather think not +++
    6)
    I did not see any comments on the above issues (?).
    
    - Santosh
     - santoshr.vcf
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:58 2001
6315 messages in chronological order