RE: iSCSI: Flow Control

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

Pierre,

What protocol are you describing?  Are you explaining TCP or your version of
TCP?

Doug


> Julian_Satran@il.ibm.com wrote:
>
> > Pierre,
> >
> > It does not matter how from where you send the data on the wire.
> > If you have a long wire and you want to cover the latency you will
> > send data as soon as you can and then commands get stuck  behind.
>
> Julian,
>
> The command can NOT  be stuck because there is "data on the wire".
> Let me give you an example,
> Let's talk again about the "pull model" adapter on the initiator.
> Imagine you have 100Mbytes of (write) data outstanding
> because 1000 cmds of large write commands have been posted to
> the adapter.
> The adapter sends this data as fast as it can. But very important,
> the data are not tossed in any kind of buffer on the adapter.
> What the adapter does is: pull some kbytes of data form host memory,
> encapsulate it, send it on the wire. Again and again, as fast as it can.
>
> Now, imagine that a read is posted to the adapter after the 1000 writes.
> Here is the point. The interface between the host and the adapter is not
> a FIFO but a flat array and the adapter can works in parallel on
> all the commands. Immediately when the host posts the read
> (in the flat array), the adapter sees it. The adapter as soon as it
> completes transmitting the current data PDU, sends the read command.
>
> The read command is not stuck behind the 100Mbytes of data.
> The maximum latency for the command is the time to
> transmit one iSCSI pdu on the wire.
> That is (size of pdu)/throughput.
>  Then the adapter continues to send the write data of the
> 100Mbytes. And as soon as a new command will be posted,
> it will send a command pdu immediately after the current
> data PDU.
>
> Commands are not stuck behind data because there is no FIFO
> before the wire, and because data "on the wire" doesn't block anything.
> The wire is always able to deliver its throughput.
>
>
> Regards,
>
> Pierre
>