Re: [dpdk-dev] [RFC] - Offloading tunnel ports

[William Tu <u9012063@gmail.com>]

On Sun, Jul 12, 2020 at 9:52 PM Oz Shlomo <ozsh@mellanox.com> wrote:
>
> Hi William,
>
> On 7/12/2020 7:34 PM, William Tu wrote:
> > Hi Oz,
> >
snip

> >>
> >> Openvswitch, for example, uses two flows:
> >> 1. classification flow - setting the virtual port representing the tunnel type
> >> For example: match on udp port 4789 actions=tnl_pop(vxlan_vport)
> >> 2. steering flow according to outer and inner header matches
> >> match on in_port=vxlan_vport and outer/inner header matches actions=forward to port X
> >> The benefits of multi-flow tables are described in [1].
> >>
> >> Offloading tunnel ports
> >> -----------------------
> >> Tunnel ports introduce a new stateless field that can be matched on.
> >> Currently the rte_flow library provides an API to encap, decap and match
> >> on tunnel headers. However, there is no rte_flow primitive to set and
> >> match tunnel virtual ports.
> >>
> >> There are several possible hardware models for offloading virtual tunnel port
> >> flows including, but not limited to, the following:
> >> 1. Setting the virtual port on a hw register using the rte_flow_action_mark/
> >> rte_flow_action_tag/rte_flow_set_meta objects.
> >> 2. Mapping a virtual port to an rte_flow group
> >> 3. Avoiding the need to match on transient objects by merging multi-table
> >> flows to a single rte_flow rule.
> >>
> >> Every approach has its pros and cons.
> >> The preferred approach should take into account the entire system architecture
> >> and is very often vendor specific.
> >
> > Are these three solutions mutually exclusive?
> > And IIUC, based on the description below, you're proposing solution 1, right?
> > and the patch on OVS is using solution 2?
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fopenvswitch%2Fcover%2F20200120150830.16262-1-elibr%40mellanox.com%2F&amp;data=02%7C01%7Cozsh%40mellanox.com%7C4ece31d745d246e30f9308d8268185cb%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637301685025981024&amp;sdata=mPCFG468xYkHRX3HJRkrrDix4hfDLstAZtlILQfGxr8%3D&amp;reserved=0
> >
>
>  From the OVS patchset we learned that it might be better to provide each vendor
> with the flexibility to implement its optimal hardware model.
> We propose this design as an alternative to the submitted OVS patchset.
>
> This patch is designed to provide an abstract API.
> As such, any of the solutions listed above, or others, are possible.
> The Mellanox PMD is planned to implemented solution 2.
>
>
> >>
> >> The proposed rte_flow_tunnel_port_set helper function (drafted below) is designed
> >> to provide a common, vendor agnostic, API for setting the virtual port value.
> >> The helper API enables PMD implementations to return vendor specific combination of
> >> rte_flow actions realizing the vendor's hardware model for setting a tunnel port.
> >> Applications may append the list of actions returned from the helper function when
> >> creating an rte_flow rule in hardware.
> >>
> >> Similarly, the rte_flow_tunnel_port_match helper (drafted below) allows for
> >> multiple hardware implementations to return a list of fte_flow items.
> >>
> > And if we're using solution 1 "Setting the virtual port on a hw
> > register using the rte_flow_action_mark/
> > rte_flow_action_tag/rte_flow_set_meta objects."
> > For the classification flow, does that mean HW no longer needs to
> > translate tnl_pop to mark + jump,
> > but the HW can directly execute the tnl_pop(vxlan_vport) action
> > because the outer header is
> > saved using rte_flow_set_meta?
> >
>
> In this case we would need to map the outer header fields to a unique id.
> This can be done either from the datapath (for capable hardware) or from the
> flows. The latter option, requires the flow to match on the outer header fields
> that should be stored. OVS matches on the outer header fields only after it
> classifies the tunnel port (i.e. after the tnl_pop action).
>
Hi Oz,
Thanks for your explanation. It's much more clear to me now.
William