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.



    Charles,
    
    "Binford, Charles" wrote:
    
    > 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".
    
    You raise a good point here. Note that the iscsi definition of FirstBurstSize
    in its disconnect-reconnect mode page differs from SPC-2 definition in that it
    is silent about the semantics of a 0 value for the FirstBurstSize. Perhaps,
    Julian can comment on whether this was intentional to indicate that 0 implies
    no buffer available, or was an omission, in which case the wording needs to be
    fixed.
    
    
    > 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.
    
    Agreed.
    
    
    > 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.
    
    I am in favor of this technique as well. As I have argued in the past,
    dependence on the mode sense/select for iscsi session parameters is not a good
    idea for several reasons :
    
    
       * Mode Sense/Select implementation may be a shared mode page implementation
         and this can cause strange side effects on initiators when other
         initiators establish sessions with that target port and issue mode select.
         It can result in mode select wars between initiators if they are
         attempting to use different settings and are concurrently operating with
         the same target port.
    
       * Mode Sense/Select for setting session parameters is not architecturally as
         clean as setting these parameters through login keys, since login keys are
         an iscsi in-band technique, applied on a per session basis and only affect
         the specified initiator & target port in that I-T nexus.
    
       * Usage of mode sense followed by mode select causes an increase in I/O scan
         times since this implies 2 extra scsi commands per session establishment.
         Compare this with setting these parameters through the use of login keys,
         which is done during login phase, has no side effects of affecting other
         initiators and is a faster and more optimal method.
    
       * Negotiating all session parameters through login keys allows initiator
         implementations to be simpler since they can avoid having SCSI command set
         code in the iscsi initiator drivers.
    
    For all of the above reasons, I am very much in favor of using login keys for
    negotiating session parameters, rather than dependence on mode select/sense.
    
    
         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 t
    > the mode pagan at all.  (my preferred choice)
    
    This is my preferred choice as well. Going with these choices will keep
    initiator implementations simpler, optimize session establishment time [and
    thereby, I/O scan time for initiators], avoid mode select wars and other side
    effects of shared mode pages on iscsi initiator drivers.
    
    I would like to request folks to re-consider the use of mode sense/select for
    setting session parameters given the above listed reasons. My preference is to
    only depend on iscsi login keys and state that iscsi has no meaning for the
    disconnect-reconnect mode page.
    
    Regarding the "Enable CRN" issue, I will reply in a separate mail.
    
    Thanks,
    Santosh
    
    
    
    
    
         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.
         > > >
         > > >
         > >
    
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

Last updated: Fri Sep 21 13:17:17 2001
6662 messages in chronological order