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

Simon Horman simon.horman at netronome.com
Wed Dec 21 17:19:16 CET 2016


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,

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?

  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.

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

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

With the above questions in mind I am curious to know what use-cases
the proposal is targeted at.


More information about the dev mailing list