SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Command Queue Depth (was asymmetric/Symmetric)



    
    
    Dear colleagues,
    
    Although the windowing mechanism in iSCSI-01 may seem to be there to solve
    a queueing issue
    it is mainly meant to limit the buffering space for commands that await
    "de-skewing".
    We assume that execution queue-lengths, policy etc. are beyond the scope of
    transport.
    
    As for SCSI queue length I assumed that the busy or queue full status
    followed by an Asynch Event
    message indicating readiness is the mechanism provided by SCSI to regulate
    the command flow.
    
    It is hard to imagine that give the variable life-time of SCSI commands and
    the
    opaque nature of the resources required to execute them  that the transport
    has
    to help in this area.
    
    Julo
    
    Jim McGrath <Jim.McGrath@quantum.com> on 07/09/2000 06:06:40
    
    Please respond to Jim McGrath <Jim.McGrath@quantum.com>
    
    To:   "'Matt Wakeley'" <matt_wakeley@agilent.com>, ips <ips@ece.cmu.edu>
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  RE: Command Queue Depth   (was asymmetric/Symmetric)
    
    
    
    
    
    The issue of buffer space allocation for multiple initiators has a long and
    troubled history in SCSI.  We have never been able to come up with a good
    answer.
    
    Fibre Channel tried to fix this with the notion of "login BB credit" - when
    you login you get a minimum number of credits you are always guaranteed
    when
    you start data transfers.  The problem with this is that storage devices
    had
    no realistic ability to discriminate between initiators or to change the
    login BB credit.  In addition, the expectation is that all possible
    initiators would get these credits on login.  So storage devices vendors
    have played it safe and kept this number low (at 0 until recently, now
    around 2).  For iSCSI the number of initial credits you need to "prime the
    pump" until normal data flow is established is probably large (given the
    latencies are higher than in Fibre Channel, especially FC-AL), and the
    number of potential initiators larger than in Fibre Channel, making this a
    whole lot worse for the storage device.
    
    As soon as we allow the devices to start adjusting these credits, then you
    have the protocol problem of making sure people know when their credits are
    adjusted and the policy problem of how, who, and when to adjust the
    credits.
    Changing everyone's credit when you add a new initiator can get into a
    notification nightmare, although it is "fair."  Any policy brings up all
    sorts of nasty issues regarding fairness vs efficient use of the
    transmission media.
    
    Jim
    
    Note: the same problem has plagued other attempts to allocate device
    resources between multiple initiators, like command queue space.  In
    general
    policies with respect to multiple initiators are not really standard in the
    SCSI world.
    
    
    -----Original Message-----
    From: Matt Wakeley [mailto:matt_wakeley@agilent.com]
    Sent: Wednesday, September 06, 2000 2:56 PM
    To: ips
    Subject: Re: Command Queue Depth (was asymmetric/Symmetric)
    
    
    Joshua Tseng wrote:
    
    > James,
    >
    > I agree with others that there may be an issue with the
    > command windowing mechanism in the existing iSCSI spec.  It is like
    > "TCP in reverse", in that the target determines the size of the window,
    and
    > not the initiator as in TCP.  Rather, I believe that everything that this
    > windowing mechanism is attempting to achieve can be more easily obtained
    > by having the target communicate its buffer size to the initiator at
    > iSCSI login.  It should be the role of the initiator to determine how
    > many commands to put in flight simultaneously, given this input on
    available
    > buffer size from the target.
    
    As more initiators connect to a target, it may need to scale back the
    amount
    of
    this buffering it has allocated to each previously logged in initiator (to
    prevent rejecting new logins).
    
    >
    >
    > As far as multiple initiators, could this not be resolved by the target
    > refusing additional logins beyond the number of initiators it can safely
    > support?  Not being a storage expert, this is my best guess/suggestion
    > at how to do it.
    
    I believe John already answered this...
    
    -Matt
    
    
    
    


Home

Last updated: Tue Sep 04 01:07:30 2001
6315 messages in chronological order