Re: [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow)

[Simon Horman <simon.horman@netronome.com>]

On Thu, Dec 22, 2016 at 01:48:04PM +0100, Adrien Mazarguil wrote:
> On Wed, Dec 21, 2016 at 05:19:16PM +0100, Simon Horman wrote:
> > On Fri, Dec 16, 2016 at 05:24:57PM +0100, Adrien Mazarguil wrote:
> > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > > described in [3] (also pasted below), here is the first non-draft series
> > > for this new API.
> > > 
> > > Its capabilities are so generic that its name had to be vague, it may be
> > > called "Generic flow API", "Generic flow interface" (possibly shortened
> > > as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> > > the prefix used for its public symbols. I personally favor the latter.
> > > 
> > > While it is currently meant to supersede existing filter types in order for
> > > all PMDs to expose a common filtering/classification interface, it may
> > > eventually evolve to cover the following ideas as well:
> > > 
> > > - Rx/Tx offloads configuration through automatic offloads for specific
> > >   packets, e.g. performing checksum on TCP packets could be expressed with
> > >   an egress rule with a TCP pattern and a kind of checksum action.
> > > 
> > > - RSS configuration (already defined actually). Could be global or per rule
> > >   depending on hardware capabilities.
> > > 
> > > - Switching configuration for devices with many physical ports; rules doing
> > >   both ingress and egress could even be used to completely bypass software
> > >   if supported by hardware.

Hi Adrien,

apologies for not replying for some time due to my winter vacation.

> Hi Simon,
> 
> > Hi Adrien,
> > 
> > thanks for this valuable work.
> > 
> > I would like to ask some high level questions on the proposal.
> > I apologise in advance if any of these questions are based on a
> > misunderstanding on my part.
> > 
> > * I am wondering about provisions for actions to modify packet data or
> >   metadata.  I do see support for marking packets. Is the implication of
> >   this that the main focus is to provide a mechanism for classification
> >   with the assumption that any actions - other than drop and variants of
> >   output - would be performed elsewhere?
> 
> I'm not sure to understand what you mean by "elsewhere" here. Packet marking
> as currently defined is a purely ingress action, i.e. HW matches some packet
> and returns a user-defined tag in related meta-data that the PMD copies to
> the appropriate mbuf structure field before returning it to the application.

By elsewhere I meant in the application, sorry for being unclear.

> There is provision for egress rules and I wrote down a few ideas describing
> how they could be useful (as above), however they remain to be defined.
> 
> >   If so I would observe that this seems somewhat limiting in the case of
> >   hardware that can perform a richer set of actions. And seems particularly
> >   limiting on egress as there doesn't seem anywhere else that other actions
> >   could be performed after classification is performed by this API.
> 
> A single flow rule may contain any number of distinct actions. For egress,
> it means you could wrap matching packets in VLAN and VXLAN at once.
> 
> If you wanted to perform the same action twice on matching packets, you'd
> have to provide two rules with defined priorities and use a non-terminating
> action for the first one:
> 
> - Rule with priority 0: match UDP -> add VLAN 42, passthrough
> - Rule with priority 1: match UDP -> add VLAN 64, terminating
> 
> This is how automatic QinQ would be defined for outgoing UDP packets.

Ok understood. I have two follow-up questions:

1. Is the "add VLAN" action included at this time, I was not able to find it
2. Was consideration given to allowing multiple actions in a single rule?
   I see there would be some advantage to that if classification is
   expensive.

> > * I am curious to know what considerations have been given to supporting          support for tunnelling (encapsulation and decapsulation of e.g. VXLAN),
> >   tagging (pushing and popping e.g. VLANs), and labels (pushing or popping
> >   e.g. MPLS).
> > 
> >   Such features seem would useful for application of this work in a variety
> >   of situations including overlay networks and VNFs.
> 
> This is also what I had in mind and we'd only have to define specific
> ingress/egress actions for these. Currently rte_flow only implements a basic
> set of existing features from the legacy filtering framework, but is meant
> to be extended.

Thanks. I think that answers most of my questions: what I see as missing
in terms of actions can be added.

> > * I am wondering if any thought has gone into supporting matching on the
> >   n-th instance of a field that may appear more than once: e.g. VLAN tag.
> 
> Sure, please see the latest documentation [1] and testpmd examples [2].
> Pattern items being stacked in the same order as protocol layers, maching
> specific QinQ traffic and redirecting it to some queue could be expressed
> with something like:
> 
>  testpmd> flow create 0 ingress pattern eth / vlan vid is 64 / vlan vid is 42 / end 
>     actions queue 6 / end
> 
> Such a rule is translated as-is to rte_flow pattern items and action
> structures.

Thanks, I will look over that.

> > With the above questions in mind I am curious to know what use-cases
> > the proposal is targeted at.
> 
> Well, it should be easier to answer if you have a specific use-case in mind
> you would like to support but that cannot be expressed with the API as
> defined in [1], in which case please share it with the community.

A use-case would be implementing OvS DPIF flow offload using this API.

> [1] http://dpdk.org/ml/archives/dev/2016-December/052954.html
> [2] http://dpdk.org/ml/archives/dev/2016-December/052975.html