On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear <gree...@candelatech.com> wrote: > On 03/24/2016 09:45 PM, Vijay Pandurangan wrote: >> >> Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth >> to drop the packets if they have bad checksums before they hit the >> application level. > > > VETH is pretty special in that when you transmit a frame on one > device, it's pair receives it, and unless there is RAM corruption > or bugs in the kernel, then it cannot be corrupted.
Yeah, you're right that that's an optimization. However, I think that we should first ensure that a->veth->b operates exactly like: a->physical eth 1 -> physical eth 2->b in all cases. Once we have that working everywhere we could think about optimizations. If we're willing to refactor, we could implement the optimization by allowing veth devices to know whether their immediate peer is. If a veth knows it's talking to another veth, it could under some circumstances elide checksum calculation and verification. I'm not sure what abstractions that would break, though. What do you guys think? > > But, if you are routing frames from the network to veth > devices, then the original packet could be corrupted, as > described in your patch. > > Probably the right behaviour is to keep the old logic for packets > originating from sockets, at least. I am not sure of a good way > to implement that. > > As for testing, I am not sure. Probably you have to make a good > effort and then just deal with fallout like what I found. I would guess > that any of us who have ever written an interesting patch have also written > an interesting bug! > > > Thanks, > Ben > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com
