On Sun, Jul 12, 2020 at 9:52 PM Oz Shlomo <o...@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&data=02%7C01%7Cozsh%40mellanox.com%7C4ece31d745d246e30f9308d8268185cb%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637301685025981024&sdata=mPCFG468xYkHRX3HJRkrrDix4hfDLstAZtlILQfGxr8%3D&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
