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

[David Robinson <David.Robinson@EBay.Sun.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...

> > Do not forget about the buffers feeding the individual mediums.
> > A device being serviced by this server interface is only able to deliver
> > about 200 requests per second where most of these requests are small. Only
> > by joining together several targets will wire speed be possible
> > on any given connection. Unfortunately, iSCSI does not allow this
> provision
> > and hence requires a connection per target. :(

One disadvantage of multiplexing different LUs on the same TCP
connection
is that you cannot leverage the TCP flow control.  If the LUs command
buffers are full whether you assert an iSCSI level flow control or TCP
level flow control doesn't matter much.  With a shared connection it
is important that you don't TCP flow control so that one LU with a full
command queue doesn't block another that is available.

	-David