Re: iSCSI: Urgent Pointer Negotation

[Michael Krause <krause@cup.hp.com>]

At 08:53 PM 11/15/00 -0800, John Hufferd/San Jose/IBM wrote:
>Please forgive my previous send of a null message (had a finger check).
>
>Costa MIGHT have the key to this discussion.  If he is correct, that the
>Urgent Pointer takes the fast path away from the SW receive TCP Stacks, but
>perhaps not a big deal on Send (Need to check this), then I would think
>that SW implementations could almost always agree on send, but not on
>receive.  In that way, a HW TCP/IP with iSCSI NIC could get just about all
>it needed in performance improvement and Memory reductions without a
>significant impact on the SW side. Therefore, this MIGHT be a break
>through.  We need to confirm his statements, and then,  it might make since
>to have, as Costa suggested, a Login negotiation parameter for Urgent
>Pointer, in each direction.
>
>Those that really know, about the receive fast path and the send  path with
>Urgent Pointer stuff, please answer quickly.

It is really implementation specific in terms of the performance / 
complexity aspect of using URG - don't think people should be bound to a 
LCD of implementations.  In any case, URG data processing has a separate 
path and a separate set of operations to be performed.

However, all of these could be easily dealt with by

(a) knowing that the connection is being used for iSCSI (most applications 
will know this),

(b) pushing a module on top of TCP that takes care of the URG path 
processing such that a second send() is not needed, i.e. each send 
automatically generates the packet with the URG pointer noted correctly, 
and on receives, it intercepts the URG indicator so that the upper layers / 
signal issues are not hit.

This does not require a modification to TCP to compensate but to the 
overall operational stack which already includes creating an iSCSI 
interface driver sitting underneath a SCSI class driver in most 
implementations.  This isn't complex but it is some work people might want 
to consider.  Note that the iSCSI interface driver could be just this 
module depending upon the stack construction.

Negotiation on each direction seems a reasonable compromise at login time.

Mike