Re: iSCSI: Flow Control

[Julian_Satran@il.ibm.com]

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.

And nobody is suggesting you should park the data on the NIC card if
you know better.

Julo

Pierre Labat <pierre_labat@hp.com> on 09/10/2000 20:41:14

Please respond to Pierre Labat <pierre_labat@hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: Flow Control




julian_satran@il.ibm.com wrote:

> Pierre,
>
> Sorry I missed a point about a - I though you where saying that
unsolicited
> data
> are not allowed. On this we are in agreement.
>
> On the rest - I can hardly follow. The model you suggest while valid in a
> close
> scheme like a bus or short serial connection - in which the target
fetches
> data is closely matched by th R2T for data with no such match for
commands.
> Keeping track of how many commands where shipped for what LU is
impractical
> as we don't what per-LU state at the initiator (for the same reason we
> rejected
> the connection per LU model).
>
> As for D - the point is that when you have a command to send and the
> command window
> is open you might have to wait a long time as the TCP window is closed
> and/or you have
> a lot of data ahead.

I think there is a misunderstanding about the model i was talking about.
It's a pull model as implemented in some FC cards today and it is assumed
that

TCP/IP is handled on the adapter. It is the "no memory on adapter" model
Somesh talked about.

When a command comes out the SCSI layer, it is posted to the adapter.
At this point it is not posted in a queue but in a flat array of commands.
The data is till in host memory.
Let's assume the card can handle 1000 commands in parallel, the array
has 1000 entries.
The adapter is able to process this commands the way it wants
as far as it respects the protocol (iSCSI in our case). It could
be able to process them all in parallel if needed.
As it is a flat array, no commands are blocked by an other commands
or data. The adapter can pick (pull) whatever command or data
from host memory and send
it on the wire (again as far as it respect the protocol).

Regards,


Pierre