* Ted Unangst <[email protected]> [2014-01-24 17:48]: > On Fri, Jan 24, 2014 at 16:27, Christian Weisgerber wrote: > > Henning Brauer <[email protected]> wrote: > > > >> i need this tested on an sk(4). > >> I don't have that hardware at all. > > [Summary: Henning wants to confine in_cksum_phdr() to ip_output.c and > > remove its only other user sk_rxcsum().]
make in_cksum_phdr() private to ip_output kill in_cksum_addword() and to do so kill RX csum offloading in sk reasoning: it's the only user of the above two, the sk csum offloading is "interesting" because: -RX only, nothing on the TX side -rather complex, might eat up (or more) offloading benefits in many cases -the hardware miscomputes the cksums sometimes, so we don't trust it claiming a cksum is bad and re-do the cksum verification in sw then... (but we trust it to not mark bad ones good? hmmmmmmmmm.) -sk isn't exactly common or likely to be used by someone who cares about performance. the cheapest em will easily beat it. i seem to remember having some sk at some point. 1st gen AMD Athlon. another decade, almost(?) another century, long before amd64 was even on the horizon. > Some questions: How much does this rudimentary half checksumming help? I wonder about this too, on one hand and mostly out of pure interest. On the other hand, we're talking about sk(4). > How much penalty is there be to simply not using hw csum on these cards? a complete and correct csum offload, RX _and_ TX, gives roughly 7% advantage in forwarding rate on a slow-ish CPU. current xeons and the like are compute monsters hiding the efects completely. > Are people still using sk, gem, or hme (!) in pps performance critical > situations? doesn't make sense to do so, and hasn't in a long time... -- Henning Brauer, [email protected], [email protected] BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
