RE: VI (Was: Avoiding deadlock in iSCSI)

[julian_satran@il.ibm.com]

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