On Wed, Apr 21, 2021, at 10:20, Kovacevic, Marko wrote:
> > 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
> 

Thanks for the tests and the reviews done!

We are currently trying to develop a feature (port mirroring offload) that would
use the port traversal helper introduced by this series. It would help to know
if it needs further changes or if we can depend on it.

If anyone has remarks or otherwise thinks the change is good, please let us 
know.

Best regards,
-- 
Gaetan Rivet
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to