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

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

On Wed, Jan 04, 2017 at 10:53:50AM +0100, Simon Horman wrote:
> 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:
[...]
> > > 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.

OK, then a high level definition would be that PMDs perform all actions part
of a flow rule, and applications are left to handle what they did not
explicitly request to be offloaded.

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

It has not been defined yet. All egress offload actions remain to be
defined.

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

Yes, it is supported as described in the documentation (now available
on-line since the series has been applied [3]).

What is not supported however is requesting the same action to be performed
multiple times in a single flow rule, because order is not guaranteed by
design. Actions may all happen simultaneously.

This scenario can be handled with multiple rules using priorities as in my
QinQ example above, or through a new action performing several things at
once in a defined order (e.g. a single "QinQ" action).

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

OK, OVS has been mentioned several times in this thread and my understanding
is that rte_flow seems to accommodate most of its needs according to people
familiar with it. Perhaps ML archives can answer the remaining questions you
may have about combining rte_flow with OVS.

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

[3] http://dpdk.org/doc/guides/prog_guide/rte_flow.html

-- 
Adrien Mazarguil
6WIND