[ovs-git] [openvswitch/ovs] 498fe0: Prepare for post-2.13.0 (2.13.90).

jahurley noreply at github.com
Tue Jan 28 20:07:33 UTC 2020


  Branch: refs/heads/branch-2.13
  Home:   https://github.com/openvswitch/ovs
  Commit: 498fe04810d12b21cf15b6a78a8afab0ee028d49
      https://github.com/openvswitch/ovs/commit/498fe04810d12b21cf15b6a78a8afab0ee028d49
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2020-01-28 (Tue, 28 Jan 2020)

  Changed paths:
    M NEWS
    M configure.ac
    M debian/changelog

  Log Message:
  -----------
  Prepare for post-2.13.0 (2.13.90).

Acked-by: Gurucharan Shetty <guru at ovn.org>
Signed-off-by: Ben Pfaff <blp at ovn.org>


  Commit: 10b4c80bd3557dbc30c6dcecc00e892fa4041c54
      https://github.com/openvswitch/ovs/commit/10b4c80bd3557dbc30c6dcecc00e892fa4041c54
  Author: John Hurley <john.hurley at netronome.com>
  Date:   2020-01-28 (Tue, 28 Jan 2020)

  Changed paths:
    M lib/netdev-offload-tc.c

  Log Message:
  -----------
  tc: handle packet mark of zero

Openstack may set an skb mark of 0 in tunnel rules. This is considered to
be an unused/unset value. However, it prevents the rule from being
offloaded.

Check if the key value of the skb mark is 0 when it is in use (mask is
set to all ones). If it is then ignore the field and continue with TC offload.

Only the exact-match case is covered by this patch as it addresses the
Openstack use-case and seems most robust against feature evolution: f.e. in
future there may exist hardware offload scenarios where an operation, such
as a BPF offload, sets the SKB mark before proceeding tho the in-HW OVS.
datapath.

Signed-off-by: John Hurley <john.hurley at netronome.com>
Co-Authored-by: Simon Horman <simon.horman at netronome.com>
Signed-off-by: Simon Horman <simon.horman at netronome.com>
Acked-by: Aaron Conole <aconole at redhat.com>


Compare: https://github.com/openvswitch/ovs/compare/da3828f03b65...10b4c80bd355


More information about the git mailing list