SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: MaxBurstSize



    Pat,
    
    The MaxBurstSize login key is a don't care for iscsi initiators. It
    serves mostly an informational purpose, letting the initiator know at
    login time as to what is the maximum amount of data it can expect the
    target to request in 1 R2T request, or the maximum amount of data it can
    receive from the target in 1 data-in sequence.
    
    Most initiators should be negotiating this to the maximum possible
    value, thereby, indicating to the target to just return the maximum
    value it supports for MaxBurstSize.
    
    The MaxBurstSize itself is inherited as one of the tunables from the
    scsi Disconnect-Reconnect Mode Page as defined in SPC-2, which is to be
    re-defined for each SCSI transport as appropriate.
    
    IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode
    page makes sense in the parallel scsi context alone, where, either side
    (initiator or target) can specify how long the scsi bus can remain in
    the data phase before a disconnect must be done.
    
    In a fabric based SCSI transport, where, the data transfer does not
    cause any bus to be tied down, and the initiator's data buffers are
    allocated up-front before the SCSI command is sent to the target, I
    don't see any practical use of this key for initiators other than being
    informational, and allowing them to learn of the target's limits
    up-front at login time.
    
    I don't see why iSCSI needs to define this key, if its informational
    utility is of little or no value. I am also curious about what value
    FCP-2 initiators would find in this tunable. (?)
    
    Regards,
    Santosh
    
    
    
    "THALER,PAT (A-Roseville,ex1)" wrote:
    > 
    > Julian,
    > 
    > I still don't see the rational for MaxBurstSize.
    > 
    > The initiator doesn't need it to limit its required resources. The initiator
    > has to have its buffers allocated when it issues a command. It has to
    > control the demand on its resources by limiting the commands it issues based
    > upon its available resources.
    > 
    > The target has FirstBurstSize and R2T's to control the demand on its
    > resources.
    > 
    > The other use of MaxBurstSize is to limit how often target may set the A
    > bit, but the utility of this is unclear.
    > 
    > Regards,
    > Pat Thaler
    > 
    > ---Original message----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Tuesday, February 12, 2002 12:33 AM
    > To: Robert D. Russell
    > Cc: ips@ece.cmu.edu
    > Subject: Re: UNH Plugfest
    > +++
    > 
    > <Section 3.8.3 should be 10.8.3>
    > 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
    >   an R2T to at most MaxBurstSize.  What is the rationale for this?
    >    An R2T is sent by the target to the initiator, so why can't the
    >   target specify any size it wants in the R2T?  The target already
    >   uses R2Ts to control the flow of Data-Out PDUs from the initiator,
    >   so why impose this restriction on the R2Ts?
    > 
    >   Could someone please explain the benefit to this limitation on R2Ts?
    > 
    > +++ Is this a plugfest question or one of your own?  For your own questions
    > the channels are always open.  The MaxBurstSize is there to enable the
    > initiator to share resources between several executing commands and limit
    > the number of "pending buffers" a target will have to keep
    > in case one of the Data Out PDUS is damaged and transfer to a device is not
    > possible.
    > 
    > +++
    
    -- 
    ##################################
    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: Thu Feb 21 17:18:02 2002
8831 messages in chronological order