Rick Jones wrote: > Ryan Malayter <[EMAIL PROTECTED]> wrote: >> 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). > > Segmentation offload works simply by "cloning" the TCP header, and > updating the sequence number. That can be done by "idiot savant" > hardware that has no idea about the remote receive window, the current > congestion window etc etc. It is simply told "here is an N byte TCP > ubersegment, and the MSS is M - respond accordingly" > > My impression is that Dave Miller and the rest of the netdev folks > consider that a stateless offload. > >> 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. > > One of the biggies is bypassing all their firewall work - they hate > that idea :) > >> 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. > > With TSO on the sending side and LRO on the receiving side it is > possible to get to 10GbE link-rate with a single connection and not > great gobs of CPU horsepower. > >> 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)? > > I'm not sure where the "checksum in host" vs "checksum on NIC" > cross-over is for UDP in various stacks, but many NICs can and do > perform CKO on UDP datagrams in addition to TCP. Heck, the HP-PB (aka
Linus and a lot of others, including me, really wants to keep the TCP checksum algorithm in the cpu, not on -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
