Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

[Ben Greear <greearb@candelatech.com>]

On 04/07/2016 08:11 AM, Vijay Pandurangan wrote:
> On Fri, Mar 25, 2016 at 7:46 PM, Ben Greear <greearb@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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com