> -----Original Message-----
> From: dev <[email protected]> On Behalf Of Sriharsha
> Basavapatna via dev
> Sent: Thursday 8 April 2021 18:04
> To: Eli Britstein <[email protected]>
> Cc: ovs dev <[email protected]>; [email protected]; Ilya
> Maximets <[email protected]>; Ameer Mahagneh
> <[email protected]>; Majd Dibbiny <[email protected]>
> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
>
> On Wed, Apr 7, 2021 at 2:50 PM Eli Britstein <[email protected]> wrote:
>
> >
> > On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:
> >
> >
> > On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein <[email protected]> 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
> >>
> >> GitHub Actions:
> >> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> >> v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> >> v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> >> v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> >> v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> >> v6: https://github.com/elibritstein/OVS/actions/runs/716304028
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
> >> [2] 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
> >>
> > Acked-by: Sriharsha Basavapatna
> <[email protected]>
>
> Thanks,
> -Harsha
>
Tested-by: Emma Finn <[email protected]>
> >
> >>
> > 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.
> >
> >
>
> --
> 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
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
