Re: VI (Was: Avoiding deadlock in iSCSI)

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

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)