[ovs-dev] [PATCH rebase 3/3] ovn-controller: Use UDP checksums when creating Geneve tunnels.

[Ryan Moats]

"dev" <dev-bounces at openvswitch.org> wrote on 08/11/2016 07:20:34 PM:

> From: Jesse Gross <jesse at kernel.org>
> To: dev at openvswitch.org
> Date: 08/11/2016 07:22 PM
> Subject: [ovs-dev] [PATCH rebase 3/3] ovn-controller: Use UDP
> checksums when creating Geneve tunnels.
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> Currently metadata transmitted by OVN over Geneve tunnels is
> unprotected by any checksum other than the one provided by the link
> layer - this includes both the VNI and data stored in options. Turning
> on UDP checksums which cover this data has obvious benefits in terms of
> integrity protection.
>
> In terms of performance, this actually significantly increases throughput
> in most common cases when running on Linux based hosts without NICs
> supporting Geneve offload (around 60% for bulk traffic). The reason is
> that generally all NICs are capable of offloading transmitted and
received
> UDP checksums (viewed as ordinary UDP packets and not as tunnels). The
> benefit comes on the receive side where the validated outer UDP checksum
> can be used to additionally validate an inner checksum (such as TCP),
which
> in turn allows aggregation of packets to be more efficiently handled by
> the rest of the stack.
>
> Not all devices see such a benefit. The most notable exception is
hardware
> VTEPs (currently using VXLAN but potentially Geneve in the future). These
> devices are designed to not buffer entire packets in their switching
engines
> and are therefore unable to efficiently compute or validate UDP
checksums.
> In addition certain versions of the Linux kernel are not able to fully
> take advantage of Geneve capable NIC offloads in the presence of
checksums.
> (This is actually a pretty narrow corner case though - earlier versions
of
> Linux don't support Geneve offloads at all and later versions support
both
> offloads and checksums well.)
>
> In order avoid possible problems with these cases, efficient checksum
> receive performance is exposed as an encap option in the southbound
> database as a hint to remote senders. This currently defaults to off
> for hardware VTEPs and on for all other cases.
>
> Signed-off-by: Jesse Gross <jesse at kernel.org>
> ---

Patch 2/3 never made my mailbox, so I'm using this to comment on both
patches

While I understand patch 2/3 does and I like, I'd like it even better if
it had test cases that would help me understand the changes that weren't
picked up by the original code, because that's a potential future
regression.

Assuming that is handled in a follow-on patch, consider this an ack on
both parts 2 and 3...

Acked-by: Ryan Moats <rmoats at us.ibm.com>