Re: iSCSI: Flow Control

[Pierre Labat <pierre_labat@hp.com>]

Douglas Otis wrote:

> Pierre,
> <snip>
> > Let me answer to your objections to a) and d) here.
> > First d)
> > Let's assume we have a iSCSI adapter of the type SCSI/FC on which
> > the server posts commands and is only informed of the completion.
> > Every thing else is managed by the adapter.
> > In fact this adapter works as a pull machine.
> > It contemplates a bunch of commands posted (with pointers
> > on the data buffers associated) and decides what to pull
> > from host memory after each iSCSI PDU sent on the wire.
>
> This is describing FC as it exists with use of the command window but rather
> than frame control, this has been changed to command control.  This lacks
> the benefit of improving write latency with unsolicited WRTCMD-DATA.  To
> allow adequate resolution, going back to a frame control would once again
> restore the required control and allow mixed commands and data.
>
> If you exclude WRTCMD-DATA, then the adapter would have no choice but to
> send commands unsolicited.

Doug,


WRTCMD-DATA is it a write with immediate data?

In this case, whatever you do you, the next command/task management request
needs to wait the time the PDU (command+immediate data) is transmit on
the wire. If an application wants immediate data, it will have some added
latency for the other commands. It's up to the application to
find the right trade-off between write data transmit latency and
command transmit latency.
Buffer management can't do nothing for that.



>
>
> > Here you can add cleverness in the adapter to help us:
> > 1  after each PDU is sent the adapter enter a loop:
> >
> > 2  for each command posted, encapsulate and
> >    send the command (in order). Do that for all the commands
> >    posted to it and not yet sent (stop if the command window is closed)
> > 3 when the commands requests are exhausted
> >    the target sends data till a new command is posted. At
> >    this point it restarts in 1
> >
> > Doing that allows the commands to pass the data.
> > However the order between the commands is preserved.
> >
> > Now if you use another kind of adapter (for example
> > a regular LAN adapter and if you run TCP/IP
> > on the host, it will not work.
>
> This statement is not altogether accurate.  You are assuming data requests
> by the target are sitting on a transmit queue. If data is requested in
> smaller bursts and handled in a similar fashion to TCP windowing, then you
> would not jam the transmit buffer.  This would require an intelligent target
> that knows not to get too far ahead of data requests.

Humm, if you want something as TCP windowing you  need a big window if you have

a large latency in the network to avoid underun the target. May be
you think about a solution with SCTP (i am not familiar with it), one stream
for data and one stream for command inside a same connection?
Anyway with one TCP connection, you can't do that. If you use
one TCP connexion for command and one for data with comes back
to the synchronization problems.

>
>
> > However, the main market will be using adapters
> > "a la" SCSI, no?
>
> No. If you require separate network connections to a client, then you have
> substantially reduced the benefit of making the SAN common to IP.  FC
> already works well and would make a better choice if two adapters would be
> required.

You are right, it is an advantage to have only one card for the network
traffic. This doesn't  means that that card can't have too a
"transaction" interface "a la" FC.


Regards,

Pierre