SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: VI (Was: Avoiding deadlock in iSCSI)



    
    
    Charles,
    
    This goes to the hearth of problem.
    To avoid this effect we propose (like FCP) unordered messages to go always
    through -
    allow the initiator to decide which task management messages he deems
    "urgent".
    But if you have a single connection and the TCP window is closed you are
    left with only
    one think to do - drop the connection (and that is exactly what FCP is
    doing for similar
    reasons!).
    
    Julo
    
    Charles Monia <cmonia@NishanSystems.com> on 16/09/2000 01:19:37
    
    Please respond to Charles Monia <cmonia@NishanSystems.com>
    
    To:   Stephen Byan <Stephen.Byan@quantum.com>, IPS Reflector
          <ips@ece.cmu.edu>
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  RE: VI (Was: Avoiding deadlock in iSCSI)
    
    
    
    
    
    
    > -----Original Message-----
    > From: Stephen Byan [mailto:Stephen.Byan@quantum.com]
    > Sent: Wednesday, September 13, 2000 6:22 AM
    > To: IPS Reflector
    > Subject: RE: VI (Was: Avoiding deadlock in iSCSI)
    >
    >
    > Matt Wakeley [mailto:matt_wakeley@agilent.com] wrote:
    >
    > > I don't think VI/TCP helps at all.  The VI is implemented on
    > > top of a TCP
    > > stream.  If the TCP stream delivers the iSCSI command to VI,
    > > and VI has no
    > > place to put it, what is VI going to do?  It has to block the
    > > TCP stream, and
    > > that in turn will block and "RDMA" from occurring.
    >
    > If I understand correctly, VI/TCP has a credit-based flow
    > control mechanism
    > on its message queues (which would be used to implement the
    > iSCSI command
    > reception queue), and so the initiator would never send an
    > iSCSI command
    > without a target buffer in which to store it. So RDMA cannot block on
    > commands in the TCP stream.
    >
    
    In the context of generic ULP "flow control" issues, the following
    observations are offered.
    
    Assuming one VI/TCP message queue handles all SCSI control traffic for a
    target, using flow control on messages to prevent the "queue-full"
    condition
    has undesirable side effects. Specifically, back pressure due to lack of
    command context resources within a logical unit would stop the flow of
    commands and task management requests to all other LUNS (a form of "head of
    line" blocking).
    
    There's another issue that is perhaps less obvious. Even if multiple
    message
    queues are used, say one per LUN, stopping the flow of messages due to a
    queue full condition would also stop the flow of task management messages
    as
    well.
    
    Charles Monia
    Senior Technology Consultant
    Nishan Systems Corporation
    email: cmonia@nishansystems.com
    voice: (408) 519-3986
    fax:   (408) 435-8385
    
    
    
    
    


Home

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