cvs commit: src/sys/netinet/libalias alias_ftp.c alias_irc.c alias_local.h alias_proxy.c alias_skinny.c alias_smedia.c alias_util.c

[Andrew Gallatin]

Luigi Rizzo [rizzo at icir.org] wrote:
> On Mon, Jun 27, 2005 at 06:21:55PM +0300, Ruslan Ermilov wrote:
> ...
> > Why can't we just say that checksum offloading is incompatible
> > with NAT (like with many other things), and do the software
> > checksum calculations in libalias?
> 
> actually the more i see it the more i think checksum offloading
> is a disgrace rather than a performance boost.
> 
> it needs a lot of special cases throughout the protocol stack
> to be supported properly, which constitutes extra overhead
> with low-end hardware which does not support the offloading;
> 
> it does not pay on small packets such as acks where you have
> to touch the whole packet anyways;

There are definately tradeoffs, but let's not throw the baby
out with the bathwater.

In terms of IP header checksum offload, I could not find any case
where doing IP header checksums in our (relatively slow) 333MHz
network proccessor was faster than doing them on the 10x faster host
CPU.  This is mainly because the host has to touch the header anyway,
so its already going to take the cache misses to access it. So our
driver/firmware does not support IP header checksum offload, but it
does support TCP and UDP checksum offload.

Where checksum offload really buys you something is when you're on an
endstation, and you're not touching the data at all (sendfile sends)
or when you're not touching the data for a long time (recv into a
socket buffer where the app does not check it for a while).  On our
4Gb/sec adapters, checksum offloading is the difference between being
able to send via sendfile at 3.95 Gb/sec vs 3.2Gb/sec with a higher
CPU utilization.   And this is on an SMP P4 where the sfbuf code does
some expensive VM magic.  The difference would be more pronounced on
an opteron. 

With 10GbE just around the corner, avoiding data touches is more
important than ever.

Drew