> On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote: > > > > On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein <el...@nvidia.com > > <mailto:el...@nvidia.com>> wrote: > > > > VXLAN decap in OVS-DPDK configuration consists of two flows: > > F1: in_port(ens1f0),eth(),ipv4(),udp(), > > actions:tnl_pop(vxlan_sys_4789) > > F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0 > > > > F1 is a classification flow. It has outer headers matches and it > > classifies the packet as a VXLAN packet, and using tnl_pop action the > > packet continues processing in F2. > > F2 is a flow that has matches on tunnel metadata as well as on the > > inner > > packet headers (as any other flow). > > > > In order to fully offload VXLAN decap path, both F1 and F2 should be > > offloaded. As there are more than one flow in HW, it is possible that > > F1 is done by HW but F2 is not. Packet is received by SW, and > > should be > > processed starting from F2 as F1 was already done by HW. > > Rte_flows are applicable only on physical port IDs. Keeping the > > original > > physical in port on which the packet is received on enables applying > > vport flows (e.g. F2) on that physical port. > > > > This patch-set makes use of [1] introduced in DPDK 20.11, that > > adds API > > for tunnel offloads. > > > > Note that MLX5 PMD has a bug that the tnl_pop private actions must be > > first. In OVS it is not. > > Fixing this issue is scheduled for 21.05 (and stable 20.11.2). > > Meanwhile, tests were done with a workaround for it [2]. > > > > v2-v1: > > - Tracking original in_port, and applying vport on that physical > > port instead of all PFs. > > v3-v2: > > - Traversing ports using a new API instead of flow_dump. > > - Refactor packet state recover logic, with bug fix for error > > pop_header. > > - One ref count for netdev in non-tunnel case. > > - Rename variables, comments, rebase. > > v4-v3: > > - Extract orig_in_port from physdev for flow modify. > > - Miss handling fixes. > > v5-v4: > > - Drop refactor offload rule creation commit. > > - Comment about setting in_port in restore. > > - Refactor vports flow offload commit. > > v6-v5: > > - Fixed duplicate netdev ref bug. > > > > > > Can you provide some info on this bug ? and what changes were done to > > fix this ? > > With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always > non-NULL (was not like this previously), and there was this line: > > + data->netdev = vport ? netdev_ref(vport) : physdev; > > As the "vport" was always non-null, even for non-tunnels, it took > another ref of it, but in disassociate, only one close was done. > > With v6 it is like this (changed arguments names a bit) > > + data->physdev = netdev != physdev ? netdev_ref(physdev) : physdev; > > Checking the netdevs are different, not non-NULL. > > > Thanks, > > -Harsha > > > > > > Travis: > > v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552 > > v2 > > <https://travis-ci.org/github/elibritstein/OVS/builds/756418552v2>: > > https://travis-ci.org/github/elibritstein/OVS/builds/758382963 > > v3 > > <https://travis-ci.org/github/elibritstein/OVS/builds/758382963v3>: > > https://travis-ci.org/github/elibritstein/OVS/builds/761089087 > > v4 > > <https://travis-ci.org/github/elibritstein/OVS/builds/761089087v4>: > > https://travis-ci.org/github/elibritstein/OVS/builds/763146966 > > v5 > > <https://travis-ci.org/github/elibritstein/OVS/builds/763146966v5>: > > https://travis-ci.org/github/elibritstein/OVS/builds/765271879 > > v6 > > <https://travis-ci.org/github/elibritstein/OVS/builds/765271879v6>: > > https://travis-ci.org/github/elibritstein/OVS/builds/765816800 > > <https://travis-ci.org/github/elibritstein/OVS/builds/765816800> > > > > GitHub Actions: > > v1: https://github.com/elibritstein/OVS/actions/runs/515334647 > > <https://github.com/elibritstein/OVS/actions/runs/515334647> > > v2: https://github.com/elibritstein/OVS/actions/runs/554986007 > > <https://github.com/elibritstein/OVS/actions/runs/554986007> > > v3: https://github.com/elibritstein/OVS/actions/runs/613226225 > > <https://github.com/elibritstein/OVS/actions/runs/613226225> > > v4: https://github.com/elibritstein/OVS/actions/runs/658415274 > > <https://github.com/elibritstein/OVS/actions/runs/658415274> > > v5: https://github.com/elibritstein/OVS/actions/runs/704357369 > > <https://github.com/elibritstein/OVS/actions/runs/704357369> > > v6: https://github.com/elibritstein/OVS/actions/runs/716304028 > > <https://github.com/elibritstein/OVS/actions/runs/716304028> > > > > [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html > > <https://mails.dpdk.org/archives/dev/2020-October/187314.html> > > [2] https://github.com/elibritstein/dpdk-stable/pull/1 > > <https://github.com/elibritstein/dpdk-stable/pull/1> > > > > > > Eli Britstein (10): > > netdev-offload: Add HW miss packet state recover API > > netdev-dpdk: Introduce DPDK tunnel APIs > > netdev-offload: Introduce an API to traverse ports > > netdev-dpdk: Add flow_api support for netdev vxlan vports > > netdev-offload-dpdk: Implement HW miss packet recover for vport > > dpif-netdev: Add HW miss packet state recover logic > > netdev-offload-dpdk: Change log rate limits > > netdev-offload-dpdk: Support tunnel pop action > > netdev-offload-dpdk: Support vports flows offload > > netdev-dpdk-offload: Add vxlan pattern matching function > > > > Ilya Maximets (2): > > netdev-offload: Allow offloading to netdev without ifindex. > > netdev-offload: Disallow offloading to unrelated tunneling vports. > > > > Sriharsha Basavapatna (1): > > dpif-netdev: Provide orig_in_port in metadata for tunneled packets > > > > Documentation/howto/dpdk.rst | 1 + > > NEWS | 2 + > > lib/dpif-netdev.c | 97 +++-- > > lib/netdev-dpdk.c | 118 ++++++ > > lib/netdev-dpdk.h | 106 ++++- > > lib/netdev-offload-dpdk.c | 704 > > +++++++++++++++++++++++++++++++--- > > lib/netdev-offload-provider.h | 5 + > > lib/netdev-offload-tc.c | 8 + > > lib/netdev-offload.c | 47 ++- > > lib/netdev-offload.h | 10 + > > lib/packets.h | 8 +- > > 11 files changed, 1022 insertions(+), 84 deletions(-) > > > > -- > > 2.28.0.2311.g225365fb51 > > > > > > This electronic communication and the information and any files > > transmitted with it, or attached to it, are confidential and are > > intended solely for the use of the individual or entity to whom it is > > addressed and may contain information that is confidential, legally > > privileged, protected by privacy laws, or otherwise restricted from > > disclosure to anyone else. If you are not the intended recipient or > > the person responsible for delivering the e-mail to the intended > > recipient, you are hereby notified that any use, copying, > > distributing, dissemination, forwarding, printing, or copying of this > > e-mail is strictly prohibited. If you received this e-mail in error, > > please return the e-mail to the sender, delete it from your computer, > > and destroy any printed copy of it. > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Tested with burst and scatter traffic profiles on the 32vm setup I have and seen no performance drops. For burst little bit of a perf gain & with scatter I seen about 1% to 1.6 % in perf gain Tested-by: Marko Kovacevic <marko.kovace...@intel.com> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
