[ovs-git] [openvswitch/ovs] dd09b8: ovn-controller: Fix memory leak when updating tunn...

GitHub noreply at github.com
Sun Aug 14 05:57:29 UTC 2016


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: dd09b86cf1815e30822ebe2370d2319bebd3006e
      https://github.com/openvswitch/ovs/commit/dd09b86cf1815e30822ebe2370d2319bebd3006e
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-08-13 (Sat, 13 Aug 2016)

  Changed paths:
    M ovn/controller/encaps.c

  Log Message:
  -----------
  ovn-controller: Fix memory leak when updating tunnels.

When a tunnel possibly needs to be updated, we are currently allocating
a new name for it. This is not necessary and in fact nothing uses the
name, which then results in the memory being leaked.

Fixes: 1d45d5a9 ("ovn-controller: Change encaps_run to work incrementally.")
Signed-off-by: Jesse Gross <jesse at kernel.org>
Acked-by: Ryan Moats <rmoats at us.ibm.com>
Acked-by: Ben Pfaff <blp at ovn.org>


  Commit: 9263ceafbf472ac5bdb7db4dfd0368865fa082cb
      https://github.com/openvswitch/ovs/commit/9263ceafbf472ac5bdb7db4dfd0368865fa082cb
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-08-13 (Sat, 13 Aug 2016)

  Changed paths:
    M ovn/controller/encaps.c
    M ovn/controller/ovn-controller.c
    M tests/ovn-controller.at

  Log Message:
  -----------
  ovn-controller: Make encap processing more robust against changes.

Originally, processing of encapsulations simply iterated over all tables on
every wakeup and would replace anything that changed. This is somewhat
inefficient but it captured all changes.

Incremental processing avoided the need to do so much work but it could
miss several types of changes. In particular, it only monitored the chassis
table in the southbound database, so other changes (particularly in the
encap table) were not reflected. In addition, while it corrected some
changes to its data in OVS, others could go unnoticed.

This attempts to fix those issues by reflecting the most recent updates
to the southbound database in OVS at all times. It also increases safety
by avoiding the possibility of dangling pointers to old database rows and
eliminates the need to traverse the OVS database at all during most wakeups.

Fixes: 1d45d5a9 ("ovn-controller: Change encaps_run to work incrementally.")
Signed-off-by: Jesse Gross <jesse at kernel.org>
Acked-by: Ryan Moats <rmoats at us.ibm.com>
Acked-by: Ben Pfaff <blp at ovn.org>


  Commit: 36283d7884f308507039f5ed253d49c868a5aff0
      https://github.com/openvswitch/ovs/commit/36283d7884f308507039f5ed253d49c868a5aff0
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-08-13 (Sat, 13 Aug 2016)

  Changed paths:
    M ovn/controller-vtep/gateway.c
    M ovn/controller/chassis.c
    M ovn/controller/encaps.c
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-sbctl.c
    M tests/ovn-controller-vtep.at
    M tests/ovn-sbctl.at

  Log Message:
  -----------
  ovn-controller: Use UDP checksums when creating Geneve tunnels.

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>
Acked-by: Ryan Moats <rmoats at us.ibm.com>
Acked-by: Ben Pfaff <blp at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/3d0b82063761...36283d7884f3


More information about the git mailing list