On Fri, Aug 12, 2016 at 1:06 PM, Ben Pfaff <b...@ovn.org> wrote: > On Thu, Aug 11, 2016 at 05:20:34PM -0700, Jesse Gross wrote: >> 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> > > smap_get_bool() might slightly simplify some bits of this. > > The rationale about software versus hardware defaults might go into the > documentation or code somewhere, otherwise it'll probably be forgotten > over time. > > Acked-by: Ben Pfaff <b...@ovn.org>
Thanks, I improved those two areas that you mentioned and then pushed this series to master. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
