On 04/07/2016 08:11 AM, Vijay Pandurangan wrote:
On Fri, Mar 25, 2016 at 7:46 PM, Ben Greear <gree...@candelatech.com> wrote:
A real NIC can either do hardware checksums, or it cannot. If it
cannot, then the host must do it on the CPU for both transmit and
receive.
Veth is not a real NIC, and it cannot do hardware checksum offloading.
So, we either lie and pretend it does, or we eat massive amounts
of CPU usage to calculate and check checksums when sending across
a veth pair.
That's a good point. Does anyone know what the overhead actually is these days?
You could try setting up a system with ixgbe or similar, and then manually
disable csum offload using ethtool, and see how that performs in comparison
to hardware offload?
But, if I am purposely corrupting a frame destined for veth, then the only
reason
I would want the stack to check the checksums is if I were testing my own
stack's checksum logic, and that seems to be a pretty limited use.
In the common case you're 100% right. OTOH, there's something
disconcerting about an abstraction layer lying and behaving
unexpectedly. Most traffic that originates on a machine can have its
checksums safely ignored. Whatever the reason is (maybe, as you say
you're testing checksums – on the other hand maybe there's a bug in
your code somewhere), I really feel like we should try to figure out a
way to ensure that this optimization is at the very least opt-in…
I'm fine with allowing a user to force software-csum on veth devices
if someone wants to code that up, but forcing sw-csum for local frames
on veth devices should be disabled by default.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
