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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html