On Thu, Aug 11, 2016 at 7:10 PM, Ryan Moats <rmo...@us.ibm.com> wrote: > "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...
Thanks for the review - I rolled some test cases directly into this patch. While I think this is a good idea and should catch the most common types of problems, as I mentioned in the previous message to Ben I'm not sure that this is something that we can test our way out of - there are simply too many possible corner cases. A better solution would seem to be a common rule engine that can maintain mappings and invariants based some business logic. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
