Re: RDMA will be reverted

[Rick Jones <rick.jones2@hp.com>]

David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Mon, 24 Jul 2006 17:29:05 -0700
> 
> 
>>Nirvana I suppose would be the addition of a field in the header
>>which could be used for the determination of where to process. A
>>Transport Protocol option I suppose, maybe the IPv6 flow id, but
>>knuth only knows if anyone would go for something along those lines.
>>It does though mean that the "state" is per-packet without it having
>>to be based on addressing information.  Almost like RDMA arriving
>>saying where the data goes, but this thing says where the processing
>>should happen :)
> 
> 
> Since the full interpretation of the TCP timestamp option field value
> is largely local to the peer setting it, there is nothing wrong with
> stealing a few bits for destination cpu information.

Even enough bits for 1024 or 2048 CPUs in the single system image?  I have seen 
1024 touted by SGI, and with things going so multi-core, perhaps 16384 while 
sounding initially bizzare would be in the realm of theoretically possible 
before tooooo long.

> It would have to be done in such a way as to not make the PAWS
> tests fail by accident.  But I think it's doable.

That would cover TCP, are there similarly fungible fields in SCTP or other ULPs?

And if we were to want to get HW support for the thing, getting it adopted in a 
de jure standards body would probably be in order :)

rick jones