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 NIC) FDDI card of the mid 1990's did that. It could also header-data split up through NFS on the way in. All with magic "if this offset is this value" tables. I'm not remembering how we got here - it may have been related to mention of interrupt coalescing and its possible effect on packet latency. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
