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)



    Julian:
    
    
    julian_satran@il.ibm.com wrote:
    > 
    > 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!).
    > 
    This is exactly what SCTP's un-ordered message services was
    added for. It solves this very issue. 
    
    R
    
    
    > 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
    
    -- 
    Randall R. Stewart
    randall@stewart.chicago.il.us or rrs@cisco.com
    815-342-5222 (cell) 815-477-2127 (work)
    


Home

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