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:

quoted

On Wed, Dec 21, 2016 at 05:19:16PM +0100, Simon Horman wrote:

quoted

On Fri, Dec 16, 2016 at 05:24:57PM +0100, Adrien Mazarguil wrote:

[...]

quoted

quoted

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.

quoted

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.

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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.

quoted

[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