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,
    
    Comments in text.
    
    Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 18/04/2001 02:19:27
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:   T10 Reflector <t10@t10.org>
    Subject:  iSCSI : login keys & mode page settings
    
    
    
    
    All/Julian,
    
    The iSCSI draft is lacking sufficient description on the subject of mode
    page settings specific to iSCSI, their corresponding iSCSI login keys
    and the interactions between these 2 mechanisms. Specific comments
    enclosed below in that regard :
    
    
    1) The iSCSI draft needs to describe the layout of the protocol specific
    mode pages, namely, disconnect-reconnect mode page, protocol specific
    lun page and protocol specific port page as applicable to iSCSI. Such a
    figurative and textual description should be along the lines of that in
    FCP-2 Section 10.
    
    +++ I don't know what version you are reading - both 5.91and 92 have them.
    +++
    
    2) Specifically, the iSCSI draft lacks the description of the layout of
    the protocol specific lun page and in its absence, then describes a
    field from this page called
    EnableCmdRn. This field is non-existent in the SPC-2 description of this
    page in Section 8.3.10.
    
    +++ See above - this is a protocol specific page
    +++
    
    3) 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... +++
    
    4) The EnableCmdRN login key should be removed from the list of iSCSI
    login keys as this is a per-LUN key and iSCSI login keys have the scope
    of a session. IOW, EnableCmdRN should be negotiated through a mode
    select only and not through iSCSI login.
    
    +++ I realized this and you are reading old stuff !!+++
    
    
    5) On a more fundamental note, should iSCSI allow for 2 levels of
    control of I-T[-L] nexus operational parameters thru both the mode
    select/sense scsi mechanisms and iSCSI login key mechanisms ?
    
    +++ 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
    ++++
    
    Ex :
    ---------------------------------------------------------------------
    iSCSI login key         SCSI mode page parameter
    ---------------------------------------------------------------------
    DataPDULength           - Max Burst Size (Disc-reconn mode page)
    FirstBurstSize          - First Burst Size (disc-reconn mode page)
    InDataOrder             - EMDP (disconn-reconn mode page)
    EnableCmdRN             - Enable CRN (LUN control mode page)
    
    If such control is to be allowed at both the SCSI ULP and iSCSI
    transport layers, a communication mechanism should be defined to
    synchronize the state of these operational parameters across the 2
    layers when a change is made in either layer through its corresponding
    mechanisms.
    
    Ex :
    a) Change thru iSCSI login key should result in an up call to update the
    SCSI ULP.
    b) Change made thru mode select should result in a down call to update
    iSCSI LLP.
    c) Change thru iSCSI login key should result in an up call to SCSI ULP
    to cause a UNIT ATTENTION indicating "Mode Parameters Changed".
    
    +++ I view the ULP as the source for generating the text comands through a
    new interface (give some credit to implementers). Whenever this is not the
    case the SCSI will use the old mode set commands.
    ISCSI will not set parameters by its own  +++
    
    
    6) 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.
    
    
    7) If only 1 mechanism of control is desired, which of the following
    alternatives is desirable :
    i) Only settable thru mode select and seen thru mode sense
    Pros :
    ------
    - Allows 1 mechanism of control.
    - Removes the need for synchronization of these values across SCSI ULP &
    iSCSI.
    
    Cons :
    ------
    - Requires setting for all LUNs to enable for the entire session.
    
    
    ii) Settable thru iSCSI and also settable/viewable thru mode sense.
    Pros :
    ------
    - flexible and allows control thru both scsi & iSCSI.
    Cons :
    ------
    - Can lead to synchronization overheads.
    - Needs SP(save page) setting also to be communicated in synching iSCSI
    login to mode page values.
    
    
    iii) Only settable thru iSCSI and viewable thru mode sense.
    Pros:
    -----
    - Single mechanism of modification avoiding synchronization issues in
    setting.
    Cons :
    ------
    - Denies traditional mechanism of modification. (mode sense).
    - May break existing applns if enforced thru SPC-2.
    - Requires changes to SPC-2.
    - iSCSI compliance requires changes in SCSI ULP for SPC-2 compliance of
    the change to not use mode select for parameter changes that are shared
    with iSCSI.
    
    
    8) If these operational parameters are allowed to be set thru 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 ?
    
    9) Should saved page settings be allowed thru iSCSI ?
    
    
    - Santosh
     - santoshr.vcf
    
    
    
    


Home

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