RE: iSCSI: Flow Control

["Y P Cheng" <ycheng@advansys.com>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>
> Let me ask YP, and Pierre one other thing.  How do you think your proposed
> design would operate, if the Sender was using, as Pierre calls
> it, "regular networking" and the target was using your proposed design.
>  Is it still "All Singing and All Dancing"?

It is a definite YES.  The iSCSI adapter is designed to process TCP segments
per TCP specifications.  It finds the iSCSI PDUs in a TCP segment using a
250 MHz microengine with multiple operations and operands.  This is how we
do one IO every ten microseconds.  Therefore, we avoid the flow control
issues discussed by the WG.  To me, the flow control should be on how to
keep enough TCP segments inflight on a network with long latency as I have
given in a few examples in my previous emails.

> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> David Robinson
>
> Pierre,
> I don't know if I completely understand what you are proposing,
> but is seems that you are proposing to process TCP segments out
> of order.  <snip>
> If you are proposing that iSCSI simply keep receiving data without
> doing the SCSI layer processing and thus at the SCSI layer processing
> them out of order.  This is feasible but it is still subject to buffer
> restrictions that would cause data to be discarded which is the whole
> point of these flow control discussions, to minimize data being
> discarded.

May be I can step in on behalf of Pierre? :-)
No, TCP segments are processed in order and passed to application software
quickly.  In fact, if an iSCSI service provider is processing the TCP
segments at the wire speed, then there is no head-of-queue blocking problem.
The iSCSI processing is only responsible for translating a SCSI request to
iSCSI PDUs and parsing/creating TCP segments.  The processing of a SCSI
request are left to the application software which will take its own sweet
time.  There is no flow control problem in an iSCSI adapter if we move the
incoming data PDU's quickly to the buffers of the application software. We
do that using the flat-array described by Pierre or exchange table by me.
The key is the DMA hardware.

> What I strongly object to is any feature in the iSCSI layer that
> requires any direct manipulation of the TCP layer features
> like the window pointers.

There was some RDMA discussions to make the job easier for the adapter.
However, without any "enhancement" to the TCP header, we can still do it
with a few more instructions in our microcode.

> Implementations are free to violate layering as an optimization but
> it MUST be possible to have a functional implementation without
> knowing any details of the TCP implemenation.

You have put it real well.