David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
