[ovs-dev] [PATCH V7 00/13] Netdev vxlan-decap offload

Sriharsha Basavapatna sriharsha.basavapatna at broadcom.com
Thu Jun 24 06:18:19 UTC 2021


On Thu, Jun 24, 2021 at 12:23 AM Ilya Maximets <i.maximets at ovn.org> wrote:
>
> On 6/23/21 5:52 PM, Eli Britstein 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.
> > v7-v6:
> > - Adopting Ilya's diff, with a minor fix in set_error stub.
> > - Fixed abort (remove OVS_NOT_REACHED()) with tunnels other than vxlan
> >   ("netdev-offload-dpdk: Support tunnel pop action.").
>
> Thanks!  I see the only difference (beside the set_error fix) with what
> I have locally is following:
>
> diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
> index 363f32f71..6bd5b6c9f 100644
> --- a/lib/netdev-offload-dpdk.c
> +++ b/lib/netdev-offload-dpdk.c
> @@ -835,7 +835,9 @@ vport_to_rte_tunnel(struct netdev *vport,
>                            netdev_dpdk_get_port_id(netdev));
>          }
>      } else {
> -        OVS_NOT_REACHED();
> +        VLOG_DBG_RL(&rl, "vport type '%s' is not supported",
> +                    netdev_get_type(vport));
> +        return -1;
>      }
>
>      return 0;
> ---
>
> That looks good to me.  So, I guess, Harsha, we're waiting for
> your review/tests here.

Thanks Ilya and Eli, looks good to me; I've also tested it and it works fine.
-Harsha
>
> >
> > Travis:
> > v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> > v2: https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> > v3: https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> > v4: https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> > v5: https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> > v6: https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> > v7: Have a problem to run
>
> Yes, this thing is non-functional.  Even travis-ci.com doesn't work
> for me for unknown reason (I do have compute credits).
>
> Best regards, Ilya Maximets.

-- 
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.


More information about the dev mailing list