Re: Checksum offload queries

[Thomas Graf <tgraf@suug.ch>]

On 12/08/15 at 09:04am, Tom Herbert wrote:
> There are other reasons why CHECKSUM_COMPLETE is preferable:
> 
> - CHECKSUM_COMPLETE  is more robust. We have no way to validate that
> the device is actually correct in CHECKSUM_UNNECESSARY. For instance,
> how do we know that there isn't some failure in the device where
> everything is being marked as good even if it's not. With
> CHECKSUM_COMPLETE it is the host that actually makes the decision of
> whether the checksum is correct it is highly unlikely that failing
> checksum calculation on the device won't be detected. HW failures and
> bugs are real concern.
> -  CHECKSUM_UNNECESSARY does not report bad checksums. There is a
> csum_bad flag in the sk_buff that could be set if the driver detects a
> bad checksum in the packet, but no drivers seem to be setting that
> currently. So for any packets with bad checksums the stack will need
> to compute the checksum itself, so this potentially becomes the basis
> of a DDOS attack. CHECKSUM_COMPLETE does not have this problem, we get
> the checksum of the packet rather the checksum is correct or not.

If I understood Edward correctly, his proposal would be for the
card to provide both, the csum as for CHECKSUM_COMPLETE plus the
validation yes/no hint. It would be up to the kernel to decide
whether to validate itself or trust the card.

I'm all in favour CHECKSUM_COMPLETE as the only way to go but 
we should be aware that it depends on the penetration of RCO in
hardware VTEPs.