[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