SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iscsi : iscsi parameter default values



    I interpret what Santosh to say is:
    
    I->T something
    T->I ImmediataData=no
    I->T ImmediateData=no
    
    Isn't the I->T response required due to the phrases "For numerical
    negotiations, the responding party MUST respond with the required key" &
    "Binary negotiations are a restricted for of numerical negotiations"?
    
    So isn't that the "round trip" Santosh is speaking of and don't you have to
    do it?
    
    BTW, I still have a hard time seeing why an extra round trip is significant
    when, during a scan, you will have to do so much other I/O anyway (e.g.,
    inquiry, test unit ready, send diagnostic, start unit, read capacity, report
    luns, etc.).
    
    Eddy
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Saturday, September 29, 2001 2:43 AM
    To: ips@ece.cmu.edu
    Subject: Re: iscsi : iscsi parameter default values
    
    
    
    Santosh,
    
    The text for 08 is now:
    
       In "numerical" negotiations, the offering and responding party state
    a
       numerical value. The result of the negotiation is key dependent;
       frequently the lower or the higher of the two values is used.
    
       For numerical negotiations, the responding party MUST respond with
    the
       required key.
    
       Binary negotiations (for keys taking the values yes or no) are a
       restricted form of numerical negotiations and the result is a key
       dependent Boolean function of the two inputs. The negotiation MAY
       proceed only up to the point where both parties can unequivocally
       compute the result; continuing beyond this point is OPTIONAL (e.g.,
    if
       the function is AND and one of the parties says "no" then this may
    end
       the negotiation).
    
       The value "?" with any key has the meaning of enquiry and should be
       answered with the current value or "NotUnderstood".
    
       No round trip needed for your example.
       Julo
    
    
    
    
    
    
                        Santosh Rao
    
                        <santoshr@cup.       To:     ips@ece.cmu.edu
    
                        hp.com>              cc:
    
                        Sent by:             Subject:     Re: iscsi : iscsi
    parameter default values
                        owner-ips@ece.
    
                        cmu.edu
    
    
    
    
    
                        28-09-01 21:03
    
                        Please respond
    
                        to Santosh Rao
    
    
    
    
    
    
    
    
    John & Julian,
    
    I agree with you that ImmediateData is a powerful performance
    optimization and initiators would like to utilize this feature as much
    as possible.
    
    However, the decision on what the default setting of ImmediateData
    should be depends on 2 factors, that are aside from initiator's
    enthusiam to use this feature :
    
    1)
    It is the most common feature set supported on most targets that should
    be considered while deciding this default. IOW, are most targets able to
    support immediate data ? Are they in a position to guarantee data
    buffers to initiators up-front, not knowing how many initiators would be
    concurrently logged in and how much concurrent I/O load they would be
    receiving from the logged-in initiators ?
    
    2)
    The decision of the default is also partly influenced by the outcome of
    a seperate mail thread I've initiated with the subject "iscsi : target
    originated negotiation". Julian, can you please clarify in the wake of
    comments from Eddy Quicksall & Rod Harrison on this issue ? I see this
    as an area of interop concern since different folks are interpreting the
    spec differently.
    
    Of particular interest from that thread to this discussion, is the case
    where most targets do not support ImmediateData [due to the factors
    mentioned in (1) above] and most initiators are attempting to use
    ImmediateData [due to the performance boosts it provides], but, are
    using the default of "yes" to negotiate this feature.
    
    In this case, the target would be compelled to originate the
    ImmediateData="no" key in order to break the default. Now, if initiators
    (the responder to the negotiation, in this case) are required to respond
    to this key originated by the target, then, this is going to cause extra
    round-trips in the login process for the sole purpose of both sides
    agreeing that ImmediateData is not to be used.
    
    It would help to have clarification on how the target originated
    negotiation culminates, since that is a factor in deciding this default.
    
    Thanks,
    Santosh
    
    John Hufferd wrote:
    >
    > Robert,
    > We have had this debate before, and I guess the sides are still
    polarized.
    > However, a number of folks believe that immediate is easier to handle
    then
    > R2T (since all the information they need is with the PDU), and the
    > conservative option.  The main discussion has been since they also
    want
    to
    > have  R2T they did not want to have two code paths. However, when
    folks
    > have looked at the effort to support immediate data, they have found
    it
    to
    > be trivial.
    >
    > The payback of NOT having multiple round trips to get the data is an
    > important feature, and when you think about all the error recovery
    items
    we
    > have been discussing, it is clear that immediate data makes every
    thing
    > easier.
    >
    > The important performance improvements are so important to iSCSI (in
    my
    > mind) that if the worse the Target has to do if it can not handle
    immediate
    > data, is to send the Text Key of "ImmediateData=no", I do not think
    this
    is
    > a problem.  We need to have this performance feature thought about as
    a
    > normal property of iSCSI, so that every one that talks about the
    advantages
    > of iSCSI can include this, with out a bunch of qualifying statements.
    > Having this as the default is one way to keep this thought at the
    front
    of
    > everyone's mind.
    >
    > .
    > .
    > .
    > John L. Hufferd
    > Senior Technical Staff Member (STSM)
    > IBM/SSG San Jose Ca
    > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > Home Office (408) 997-6136
    > Internet address: hufferd@us.ibm.com
    >
    > Robert Snively <rsnively@brocade.com> on 09/28/2001 08:25:45 AM
    >
    > To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
    > cc:   ips@ece.cmu.edu
    > Subject:  RE: iscsi : iscsi parameter default values
    >
    > I vote no as the default value on ImmediateData.
    >
    > A default value of yes on ImmediateData requires implementation
    > of the most complex and demanding mode of operation as the
    > default.  SCSI has traditionally made its default behavior the
    > simplest and most encompassing, setting more sophisticated
    > behavior by subsequent agreement.  While it may be your earnest
    > desire to encourage the implementation of this function, it
    > is not appropriate to demand that as the default behavior
    > of all devices.  In particular, there is no special benefit
    > to providing ImmediateData in low-cost local sub-lans.
    >
    > If you want to encourage it in a profile, fine, but demanding
    > it as the default in the core standard is not appropriate.
    >
    > Note that the behavior of SCSI is traditionally managed
    > entirely by the target.  As such, there has never before now
    > been a requirement for the target to, as a default, accept
    > any PDU except a command or task management function
    > that was not explicitly solicited.  That is one of the mechanisms
    > that assists SCSI in achieving a low-overhead zero copy
    > capability while operating with a large number of initiators
    > and with deep command queues.
    >
    > Bob Snively                        e-mail:    rsnively@brocade.com
    > Brocade Communications Systems     phone:  408 487 8135
    > 1745 Technology Drive
    > San Jose, CA 95110
    >
    > > -----Original Message-----
    > > From: John Hufferd [mailto:hufferd@us.ibm.com]
    > > Sent: Friday, September 28, 2001 1:33 AM
    > > To: Julian Satran
    > > Cc: ips@ece.cmu.edu
    > > Subject: RE: iscsi : iscsi parameter default values
    > >
    > >
    > >
    > > I also agree with this.  It should be yes.
    > >
    > > .
    > > .
    > > .
    > > John L. Hufferd
    > > Senior Technical Staff Member (STSM)
    > > IBM/SSG San Jose Ca
    > > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > > Home Office (408) 997-6136
    > > Internet address: hufferd@us.ibm.com
    > >
    > >
    > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM
    > >
    > > Sent by:  owner-ips@ece.cmu.edu
    > >
    > >
    > > To:   ips@ece.cmu.edu
    > > cc:
    > > Subject:  RE: iscsi : iscsi parameter default values
    > >
    > >
    > >
    > >
    > > The one that I have trouble living with is ImmediateData.
    > > This is important
    > > for low-end desktops and hardly matters for large boxes.
    > > As such I would suggest it stays as yes.
    > >
    > > Julo
    > >
    > >
    > >
    > >                     "Eddy
    > >                     Quicksall"            To:     "'Santosh Rao'"
    > > <santoshr@cup.hp.com>,
    > >                     <EQuicksall@med        <ips@ece.cmu.edu>
    > >                     iaone.net>            cc:
    > >                     Sent by:              Subject:     RE:
    > > iscsi : iscsi
    > > parameter default values
    > >                     owner-ips@ece.c
    > >                     mu.edu
    > >
    > >
    > >                     27-09-01 17:22
    > >                     Please respond
    > >                     to "Eddy
    > >                     Quicksall"
    > >
    > >
    > >
    > >
    > >
    > > I like your defaults below.
    > >
    > > But, section 5 says:
    > >
    > >  The initial Login request MUST include the InitiatorName and
    > >  SessionType key=value pairs.
    > >
    > > Since SessionType is REQUIRED, naming a default would imply a
    > > possible typo
    > > in the spec.
    > >
    > > Eddy
    > >
    > > -----Original Message-----
    > > From: Santosh Rao [mailto:santoshr@cup.hp.com]
    > > Sent: Wednesday, September 26, 2001 10:29 PM
    > > To: ips@ece.cmu.edu
    > > Subject: iscsi : iscsi parameter default values
    > >
    > >
    > > All,
    > >
    > > With the issue of mode page vs. login keys having [almost] drawn to
    a
    > > close, I would like to
    > > raise the below issues again, on the subject of default
    > > values for login
    > > keys and other iscsi
    > > parameters :
    > >
    > >
    > >    * In keeping with traditional use of scsi mode pages, iscsi
    should
    > > not specify any default
    > >      settings for any mode pages that continue to exist for iscsi.
    > > "Default values" for mode
    > >      pages are target specific and should not be bound to the
    protocol
    > > draft.
    > >
    > >    * MORE IMPORTANTLY, I read the default for EMDP as being set to 1
    > > :-<  This implies that
    > >      targets must be always prepared to deal with out of
    > > order data and
    > > initiators must be
    > >      prepared to deal with out of order data, unless the initiator
    > > performs a mode select to
    > >      disable it. [which defeats all the previous advantages
    > > gained thru
    > > mandating use of login
    > >      keys for other negotiations.]. A default, if it were to exist,
    > > should be 0. (in-order, by
    > >      default).
    > >
    > >    * Conservative specification of defaults for login keys along the
    > > following lines :
    > >                             MaxConnections = 1
    > >                             FMarker = "no"
    > >                             InitialR2T = "yes"
    > >                             BidiInitialR2T = "yes"
    > >                             ImmediateData = "no"
    > >                             DataPDULength = 16
    > >                             MaxOutstandingR2T = 1
    > >                             DataPDUInOrder = "yes"
    > >                             ErrorRecoveryLevel = 0
    > >                             SessionType = "normal"
    > >
    > >    * Should the iscsi protocol require a "Lun Control Mode Page"?
    IOW,
    > > is an EnableCRN bit
    > >      required at the transport layer ? If the device server
    capability
    > > is to be negotiated , I
    > >      suggest this bit be moved to a SCSI ULP Mode Page such as the
    > > "Control Mode Page", through a
    > >      T10 change as a part of the SCSI changes being driven by iscsi.
    > >
    > > Comments ?
    > >
    > > Thanks,
    > > Santosh
    > >
    > >
    > > Santosh Rao wrote:
    > >
    > > > There are the separate issues of :
    > > >
    > > >    * iscsi's specification of defaults for its mode pages
    > > which is not
    > > in line with mode page
    > > >      usage. This impacts the target's ability to enforce
    > > values other
    > > than the protocol
    > > >      specified default, if the initiator were to not use mode
    > > sense/select.
    > > >
    > > >    * default settings for login keys.
    > > >
    > > >    * Is there a need for the "LUN Control Mode Page" and whether
    > > "Enable CRN" should be in a
    > > >      transport specific mode page ?
    > > >
    > > > which need to be driven to closure as well.
    > > >
    > > > Regards,
    > > > Santosh
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    
    --
    ##################################
    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: Sun Sep 30 16:17:14 2001
6892 messages in chronological order