> What would you think of a flag on the receiving end like,
> "CHECKSUM_INVALID_BUT_UNNECESSARY"? It would be treated as
> CHECKSUM_UNNECESSARY in the case that the the packet is locally
> received. But if the packet is going to be forwarded instead, then
> skb_checksum_help is called on it before forwarding onward.
>
> AFAICT, wireguard isn't the only thing that could benefit from this:
> virtio is another case where it's not always necessary for the sender
> to call skb_checksum_help, when the receiver could just do it
> conditionally based on whether it's being forwarded.
Hi Jason
It is the sort of thing which breaks in hard to find ways. I've run
network simulations with machine instances running in containers. It
used veth pairs to connect the instances to a central 'switching'
namespace which did the interconnect between the instances, using lots
of bridges. After a while, my simulation got bigger than a single host
could support. So i split it over multiple servers, using GRE tunnels
between the bridges. It took me a while to notice the network was
actually in two segments, because frames going over GRE were getting
tossed with checksum issues. It was not the GRE tunnel at fault. It
took a while to trace it back to where the checksumming was turned
off, a TAP interface i think, but i don't remember.
How do you reliably decide if a frame needs checksums, when you cannot
peer down the pipe of bridges, veth, GRE tunnels and TAP interfaces
the frame is about to take?
Andrew
