RE: VI (Was: Avoiding deadlock in iSCSI)

[Charles Monia <cmonia@NishanSystems.com>]

> -----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