[ntp:questions] Sub-millisecond NTP synchronization for local network

Ryan Malayter malayter at gmail.com
Tue Dec 9 14:35:30 UTC 2008


On Mon, Dec 8, 2008 at 7:27 PM, Rick Jones <rick.jones2 at hp.com> wrote:
> I believe you are confusing TSO and LRO, which are stateless offloads
> (TCP connection state) with TOE (TCP Offload Engine) which is a
> statefull offload - TCP connection state kept in the card rather than
> the host stack.  It is indeed true there is a considerable and likely
> to continue immune response in "netdev" to TOE, but they are quite
> pleased with stateless offloads like TSO and LRO.

You're right, I was mis-remembering the scope of "No TCP Offload"
statement I linked - I read it quite a while ago. And while I think
TCP checksum offload could be considered stateless, segmentation
offload  and receive offload certainly seem to be stateful from what
I've read (the NIC deals with headers, sequence numbers, etc., and
therefore must have some knowledge of the current connection state).

So I think, perhaps, that "stateless" vs. "stateful" isn't the
deciding factor on Linux support for networking offload technologies.
It seems the kernel guys will support NIC offload techniques that are
limited in scope and don't affect things like congestion control,
instrumentation, security, etc. But they will not support full-stack
replacement (which makes a lot of sense to me). Most of the TCP stack
in Linux will always be software-based.

In any case, I agree with the kernel guys that many-core processors
will ultimately render such techniques pointless. When you have ample
CPU resources (and bus bandwidth), hardware assistance from the NIC
just adds a layer of complexity that isn't necessary. Right now,
software-only stacks have no trouble keeping up with GbE using far
less than a single modern core (even on Windows). 10GbE might change
that, but as the kernel guys argue, it will be a temporary situation,
so it's not worth a lot of effort to write NIC offload code which will
have to be supported forever.

In any case, none of this really applies to NTP, does it? Short UDP
packets, no fragmentation, no TCP checksums. Won't NTP packets always
be handled by the software-only stack on most supported platforms
(except maybe Windows with a full TOE card)?
-- 
RPM



More information about the questions mailing list