RE: VI (Was: Avoiding deadlock in iSCSI)

["Douglas Otis" <dotis@sanlight.net>]

Charles,

Depending on the capabilities of the Net-SCSI adapter, such direct copies
would be possible without resorting to VI.  Not using VI but allowing direct
placement also provides lower overhead and a safer system as pointers going
astray due to a muddled target or bit rot is not a concern.  SAM requires
buffers to be in place prior to issuing the request.  These buffers are at
the client which is where VI becomes useful.  Unless both ends of this
communication becomes VI, you have not provided a meaningful solution.
Adding VI modifies TCP.  I do not think TCP is a good choice for
implementing VI, but to make such modifications, you could equally allow
direct copies via SCSI as well.

In an attempt to improve sending FCP protocol, which is where the problem
exists, these improvements have resulted in a lossy channel. I am confident
a solution will be found.  I am also confident one could make improvements
within the transport without affecting SCSI to achieve desired results.
Should these become a form of credit (VI like) or command/data ready
signaling, these solutions should apply directly to FCP structures equally
well.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Charles Monia
> Sent: Friday, September 15, 2000 3:20 PM
> To: Stephen Byan; IPS Reflector
> 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
>