On 10/12/15 16:26, Tom Herbert wrote: > It sounds like potentially interesting work. You'll probably want my patches > that provider helper functions that allow a driver to verify that it can > offload a checksum. We'll have to update those also to allow two checksums. I have just realised something startling. Assuming the inner protocol uses the ones complement checksum in the way IP, UDP and TCP do, the outer checksum can be computed *without looking at the payload*. Why? Because the ones complement sum of (say) a correctly checksummed UDP datagram is simply the complement of the ones complement sum of the pseudo header. Similarly, the ones complement sum of a correctly checksummed IP header is zero. Therefore, the outer checksum depends _only_ on the inner and outer pseudo headers and the encapsulation headers. For example, with UDP encapsulated in VXLAN, we have the following packet structure: ETH IP UDP VXLAN inner-ETH inner-IP inner-UDP PAYLOAD and the outer checksum equals ~([outer_pseudo] + [UDP] + [VXLAN] + [inner-ETH] + ~[inner_pseudo]) where [] denotes summation, and all addition is ones complement. This can easily be computed in software, especially as the stack already has ~[inner_pseudo]: it's stored in the inner checksum field to help inner checksum offload.
Have I made a mistake in my ones-complement maths, or is outer checksum offload as unnecessary as IP header checksum offload? -- 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
