SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iscsi : default iscsi mode page settings.



    
    
    Separation of parameters was made on a (very good) sugestion made by Robert
    Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode
    pages and iSCSI related in key=value.
    
    Julo
    
    
                                                                                            
                        "Binford,                                                           
                        Charles"             To:     IPS Reflector <ips@ece.cmu.edu>        
                        <CBinford@piru       cc:                                            
                        s.com>               Subject:     RE: iscsi : default iscsi mode    
                        Sent by:              page settings.                                
                        owner-ips@ece.                                                      
                        cmu.edu                                                             
                                                                                            
                                                                                            
                        21-09-01 16:54                                                      
                        Please respond                                                      
                        to "Binford,                                                        
                        Charles"                                                            
                                                                                            
                                                                                            
    
    
    
    Santosh,  I fully agree with the intent of your comments.  One small
    problem, however, is you argue for FirstBurstSize = 0.  Based on your other
    comments I believe you are saying first burst should be disabled.  SPC-2
    (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to
    mean "no limit".  I believe that is exactly the opposite of what your are
    arguing for.  The mode page field of firstFirstSize does not have or need
    the concept of zero blocks allowed because the feature is is enabled /
    disabled via other methods; process login parameters in FCP, initialR2T and
    ImmediateData text parameters.
    
    So, we have the problem of how does a host that wants to use immediate or
    unsolicited data know how much he can send.  Options I see are:
    - define a default value for the mode page (current method in iSCSI spec).
      As I argued in previous posting, I believe this breaks basic mode page
    concepts of SCSI.
    
    - force the host to issue a mode sense before the first command with
    Data-Out.
      Not desirable, as Santosh argued in another email.
    
    - specify the amount of data the host send before the R2T during login as a
    text parameter
      What I prefer.
    
    If we go with the last choice, then one has the question of what to do with
    firstBurstSize in the mode page. Two options come to mind:
    - reflect the login specified value in firstburstsize during mode sense.
      Memory says this is how it used to be?
    
    - do nothing with it.  Let iSCSI say that parameter in the mode page has no
    meaning for the iSCSI protocol.  Move the "firstBurstSize" concept to the
    iSCSI login/text parameters and let it stay there, don't try to tie it in
    to
    the mode pagan at all.  (my preferred choice)
    
    
    Charles Binford
    Pirus Networks
    316.315.0382 x222
    
    
    -----Original Message-----
    From: Santosh Rao [mailto:santoshr@cup.hp.com]
    Sent: Thursday, September 20, 2001 6:44 PM
    To: IPS Reflector
    Subject: RE: iscsi : default iscsi mode page settings.
    
    
    All,
    
    I think we need to discuss the 2 issues of login key defaults & mode page
    defaults seperately :
    
    1) Defaults on login keys :
    ===================
    I am in favor of defining conservative defaults. Those initiators needing
    additional features should be prepared to do the additional work of
    negotiating those keys. It should'nt be the other way around.
    Thus, default settings should be :
    
    MaxConnections = 1
    FMarker = "no"
    InitialR2T = "yes"
    BidiInitialR2T = "yes"
    ImmediateData = "no"
    DataPDULength = 16
    MaxOutstandingR2T = 1
    DataPDUInOrder = "yes"
    ErrorRecoveryLevel = 0
    SessionType = "normal"
    
    I'd like to propose one more change that the LogoutLoginMinTime &
    LogoutLoginMaxTime login keys be removed from the login keys.
    
    This is because these key values are only relevant for an initiator
    re-login
    following a target originated logout or connection drop (signalled through
    an async message). The async message does contain these values and thus, it
    provides no additional value to negotiate these during login.
    
    Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most
    likely properties of the target device (how long array "xyz" goes out to
    lunch during certain infamous conditions) as opposed to a value that can be
    negotiated on a per-initiator basis.
    
    
    2) Defaults on iscsi mode pages :
    ========================
    Typically, no protocol defaults are specified for mode page settings.
    Initiators should be able to function correctly without having to do either
    mode select or mode sense. Any initiator that needs advanced settings
    should
    be prepared to do the extra work of issuing mode sense/select to enable
    these features. It should NOT be the other way around. (i.e. simple
    initiators should NOT have to first issue a mode select in order to ensure
    proper operation of their sessions).
    
    If the draft does wish to profile a set of recommended defaults for the
    iscsi, these should be conservative, where they affect the operation of
    those initiators that do not wish to perform mode select.
    
    In particular, the following defaults are required, if it is decided to
    recommend a profile of default mode page settings :
    
    Disconnect-Reconnect Mode Page
    --------------------------
    
       * EMDP = 0
    
       * MaximumBurstSize = 512 units (as it currently defined. Targets can
         request less data in its R2T and send shorter data-in sequences, if
         mode select is not used by initiators to reduce this value.)
    
       * FirstBurstSize = 0
    
    The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use
    solicited data MUST first perform mode sense/select operations to query/set
    these values. The above default setting of 128 is  in-appropriate since :
    
    a) it can cause erroneous behaviour for those initiators that do not
    perform
    mode select to explicitly turn it off, since targets for which un-solicited
    data is enabled but not used may reject/abort the I/O.
    
    b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is
    allowed for every logged-in initiator and they have no control over turning
    this off, since mode select is an initiator-driven operation.
    Closing the command window causes performance drops and is not a very
    satisfactory solution to this problem.
    
    Logical Unit Control Mode Page
    ========================
    This mode page definition can be removed from the iscsi draft since it
    governs per-LUN state information and LUN state is the realm of the
    SCSI ULP. In particular, it is the SCSI ULP that decides whether to
    enable/disable CRN, since CRN is generated by the SCSI ULP.
    
    Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level
    & not at a SCSI ULP mode page such as the Control Mode Page. (??).
    
    Could anybody comment on why CRN (a ULP feature) needs to be enabled in an
    iscsi protocol mode page ?
    Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in
    FCP specific mode pages, since early revisions of FCP did'nt specify the
    CRN
    field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was
    required to be queried/set using mode sense/select, prior to using CRN.
    
    Since iscsi supports CRN in its scsi command pdu from its initial rev, I
    don't see why "Enable CRN" is needed to be done at the iscsi protocol
    level.
    (?).
    
    Regards,
    Santosh
    
    
    
    "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
    
    > I vote for making the exchange of some text parameters MANDATORY, with no
    > defaults.
    >
    > Marj
    >
    > > -----Original Message-----
    > > From: Robert Snively [mailto:rsnively@Brocade.COM]
    > > Sent: Thursday, September 20, 2001 10:48 AM
    > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS
    > > Reflector
    > > Subject: RE: iscsi : default iscsi mode page settings.
    > >
    > >
    > > It is true that default mode settings for Mode Pages
    > > are usually arranged between buyer and vendor for
    > > maximum convenience in the buyer's systems.  It is
    > > generally true that any setting of a Mode Page will
    > > allow the protocol to operate correctly, except a few,
    > > notably the first burst size parameter if
    > > ImmediateData is set to yes.
    > >
    > > On the other hand, some of the iSCSI text keyed
    > > parameters MUST be known before the protocol will
    > > operate correctly.  ImmediateData is certainly
    > > one of those.  As a result, you have two choices:
    > >
    > >    a) Make the negotiation of all such parameters
    > >       MANDATORY during the login and after any
    > >       reset that may change them,  or;
    > >
    > >    b) Define a default state that will be guaranteed
    > >       unless and until the parameter has been explicitly
    > >       changed.
    > >
    > > Your choice.
    > >
    > > Bob
    > >
    > > > -----Original Message-----
    > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer)
    > > [mailto:sbhagat@tripace.com]
    > > > Sent: Thursday, September 20, 2001 6:59 AM
    > > > To: 'Santosh Rao'; IPS Reflector
    > > > Subject: RE: iscsi : default iscsi mode page settings.
    > > >
    > > >
    > > > Santosh,
    > > >
    > > > Where did you find these SCSI Mode page settings? At least I
    > > > could not find
    > > > it in SAM-2 document? The mode select command is available in
    > > > SPI documents
    > > > but they are meant for particular SCSI device and not for
    > > > iSCSI device?
    > > >
    > > > Be it whatever the case I would like to ask why the default value of
    > > > MaximumBurstSize is 512 units and why is the default value of
    > > > FirstBurstSize
    > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x
    > > > revisions so setting the default value of FirstBurstSize to
    > > > 128 units means
    > > > 65536 bytes or 64K Bytes and similarly the value of
    > > > Maximumburstsize is 256K
    > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB??
    > > >
    > > > Sanjeev
    > > >
    > > > -----Original Message-----
    > > > From: Santosh Rao [mailto:santoshr@cup.hp.com]
    > > > Sent: Thursday, September 20, 2001 2:04 AM
    > > > To: IPS Reflector
    > > > Subject: iscsi : default iscsi mode page settings.
    > > >
    > > >
    > > > All,
    > > >
    > > > Speaking on the subject of default settings, some questions
    > > on recent
    > > > changes to the iscsi mode select pages......
    > > >
    > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call
    > > > out default
    > > > values for the iscsi  mode pages. Per my understanding, there are no
    > > > defaults for SCSI mode pages, and all the setting are assumed to be
    > > > disabled, unless explicitly turned on/enabled through a mode select.
    > > >
    > > > IOW, the keys in scsi mode pages are defined to be enabling certain
    > > > features and the default settings are that these features are
    > > > turned off
    > > > unless a mode select is explicitly used to enable them.
    > > >
    > > > However, the iscsi mode pages seems to be using the opposite
    > > > policy and
    > > > is advertising default settings for mode pages, that too,
    > > > agreesive ones
    > > > at that! IOW, an initiator implemenation has to explicitly
    > > > issue a mode
    > > > select to disable/turn_off features rather than issue a
    > > mode select to
    > > > turn them on.
    > > >
    > > > Here's a few examples :
    > > >
    > > >    * default MaximumBurstSize : 512 units
    > > >    * default EMDP : 1 (i.e. modify data pointers is enabled
    > > by default
    > > > !)
    > > >    * default FirstBurstSize : 128 units. (i.e. initiators MUST use
    > > > solicited
    > > >      data, unless they explicitly turn it off using mode
    > > > select, since,
    > > > not
    > > >      sending solicited data when it has been negotiated
    > > > implies a target
    > > > may
    > > >      abort the I/O.
    > > >
    > > > I suggest that in keeping with the scsi mode pages, NO
    > > > default settings
    > > > be advertised for any iscsi mode
    > > > pages. i.e. all defaults are conservative (set to 0), unless
    > > > explicitly
    > > > turned on thru a mode select.
    > > >
    > > > Comments ?
    > > >
    > > > Regards,
    > > > Santosh
    > > >
    > > > "Mallikarjun C." wrote:
    > > >
    > > > > Matthew,
    > > > >
    > > > > I completely agree that the default should be "no"!  I
    > > pointed this
    > > > > out sometime ago myself.  Apart from what you point out,
    > > the default
    > > > > setting for "ImmediateData" seems to be at variance with the
    > > > > conservative default for "InitialR2T" ("yes").
    > > > >
    > > > > Julian, could you please consider this request?
    > > > >
    > > > > Regards.
    > > > > --
    > > > > Mallikarjun
    > > >
    > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
    > > > > >
    > > > > > Julian,
    > > > > >
    > > > > > Appendix D24 (ImmediateData) does not describe the result of
    > > > negotiation if
    > > > > > the two sides differ. I presume that since the default is "yes",
    > > > then only
    > > > > > if both sides agree to "no" is immediate data turned
    > > off.  Please
    > > > can this
    > > > > > be stated.
    > > > > >
    > > > > > Additionally, I feel that the default value for
    > > > ImmediateData should
    > > > be
    > > > > > "no".
    > > > > >
    > > > > > Similarly, there is no statement on MaxOutstandingR2T.
    > > Presumable
    > > > the
    > > > > > minimum is selected.
    > > >
    > > >
    > >
    
    
    
    
    
    


Home

Last updated: Fri Sep 21 16:17:14 2001
6666 messages in chronological order