On 03/24/2016 10:24 PM, Vijay Pandurangan wrote:
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?
veth ALWAYS transmits to another VETH. The problem is that when veth is
given a packet to transmit, it is difficult to know where that packet
came from.
And, adding software checksumming to veth for every frame would be a huge
performance hit.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
