"dev" <dev-boun...@openvswitch.org> wrote on 08/11/2016 07:20:34 PM:
> From: Jesse Gross <je...@kernel.org> > To: dev@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-boun...@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 <je...@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 <rmo...@us.ibm.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev