iSCSI: Keep-alive traffic (was iSCSI: more on StatRN)

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

> > The adapter treats ACK's and Pings packets separately.  It has the
> > intelligence to know the ACK of fibre channel.  It could be programmed
to
> > handle iSCSI pings.  As that in TCP-zero-copy, with cooperation from the
TCP
> > driver, the adapter can even be programmed to handle the TCP ACKs
without
> > queuing or waiting.  I guess this is a different way of avoiding
blocking.
>
> This is not how a streaming protocol like TCP works, you cannot discard
> TCP segments and then process a later ping. If you toss a TCP segment it
> will keep coming back to you repeatedly until you process it. You won't
even
> see the iSCSI ping until you have processed all the data before it. Unless
> you want the adapter to understand the ULP (which you said you did not)
> you must pass things up and the ULP must have buffers available or the
> adapter must assert TCP flow control which you said you didn't need to
do...

A TCP-Offload-Engine will interpret the TCP/IP header in order to move data
payload directly to application software.  Doug has just pointed out that in
so doing, the adapter must obey the rule of flow control specified by
RFC2960.  Since the TOE adapter is going over the TCP/IP header, all I said
was with changes to the TCP/IP software like that of zero-copy TCP function,
the adapter can generate ping-response automatically.  No, we are not
discarding any unprocessed TCP segments.