On Wed, Jan 27, 2021 at 11:40 PM Eli Britstein <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. Vport flows (e.g. F2)
> are applied on uplink ports attached to OVS.
>
> This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
> for tunnel offloads.
>
> Travis:
> v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
>
> GitHub Actions:
> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
>
> [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
>
> Eli Britstein (13):
> netdev-offload: Add HW miss packet state recover API
> netdev-dpdk: Introduce DPDK tunnel APIs
> netdev-offload-dpdk: Implement flow dump create/destroy APIs
> 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: Refactor offload rule creation
> netdev-dpdk: Introduce an API to query if a dpdk port is an uplink
> port
> netdev-offload-dpdk: Map netdev and ufid to offload objects
> 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.
>
> Documentation/howto/dpdk.rst | 1 +
> NEWS | 2 +
> lib/dpif-netdev.c | 49 +-
> lib/netdev-dpdk.c | 135 ++++++
> lib/netdev-dpdk.h | 104 ++++-
> lib/netdev-offload-dpdk.c | 851 +++++++++++++++++++++++++++++-----
> lib/netdev-offload-provider.h | 5 +
> lib/netdev-offload-tc.c | 8 +
> lib/netdev-offload.c | 29 +-
> lib/netdev-offload.h | 1 +
> 10 files changed, 1033 insertions(+), 152 deletions(-)
>
> --
> 2.28.0.546.g385c171
>
Hi Eli,
Thanks for posting this new patchset to support tunnel decap action offload.
I haven't looked at the entire patchset yet. But I focused on the
patches that introduce 1-to-many mapping between an OVS flow (f2) and
HW offloaded flows.
Here is a representation of the design proposed in this patchset. A
flow f2 (inner flow) between the VxLAN-vPort and VFRep-1, for which
the underlying uplink/physical port is P0, gets offloaded to not only
P0, but also to other physical ports P1, P2... and so on.
P0 <----> VxLAN-vPort <----> VFRep-1
P1
P2
...
Pn
IMO, the problems with this design are:
- Offloading a flow to an unrelated physical device that has nothing
to do with that flow (invalid device for the flow).
- Offloading to not just one, but several such invalid physical devices.
- Consuming HW resources for a flow that is never seen or intended to
be processed by those physical devices.
- Impacts flow scale on other physical devices, since it would consume
their HW resources with a large number of such invalid flows.
- The indirect list used to track these multiple mappings complicates
the offload layer implementation.
- The addition of flow_dump_create() to offload APIs, just to parse
and get a list of user datapath netdevs is confusing and not needed.
I have been exploring an alternate design to address this problem of
figuring out the right physical device for a given tunnel inner-flow.
I will send a patch, please take a look so we can continue the discussion.
Thanks,
-Harsha
--
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
