[dpdk-dev] [RFC] Generic flow director/filtering/classification API
Jerin Jacob
jerin.jacob at caviumnetworks.com
Mon Jul 11 12:41:43 CEST 2016
On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote:
Hi Adrien,
Overall this proposal looks very good. I could easily map to the
classification hardware engines I am familiar with.
> Priorities
> ~~~~~~~~~~
>
> A priority can be assigned to a matching pattern.
>
> The default priority level is 0 and is also the highest. Support for more
> than a single priority level in hardware is not guaranteed.
>
> If a packet is matched by several filters at a given priority level, the
> outcome is undefined. It can take any path and can even be duplicated.
In some cases fatal unrecoverable error too
> Matching pattern items for packet data must be naturally stacked (ordered
> from lowest to highest protocol layer), as in the following examples:
>
> +--------------+
> | TCPv4 as L4 |
> +===+==========+
> | 0 | Ethernet |
> +---+----------+
> | 1 | IPv4 |
> +---+----------+
> | 2 | TCP |
> +---+----------+
>
> +----------------+
> | TCPv6 in VXLAN |
> +===+============+
> | 0 | Ethernet |
> +---+------------+
> | 1 | IPv4 |
> +---+------------+
> | 2 | UDP |
> +---+------------+
> | 3 | VXLAN |
> +---+------------+
> | 4 | Ethernet |
> +---+------------+
> | 5 | IPv6 |
> +---+------------+
How about enumerating as "Inner-IPV6" flow type to avoid any confusion. Though spec
can be same for both IPv6 and Inner-IPV6.
> | 6 | TCP |
> +---+------------+
>
> +-----------------------------+
> | TCPv4 as L4 with meta items |
> +===+=========================+
> | 0 | VOID |
> +---+-------------------------+
> | 1 | Ethernet |
> +---+-------------------------+
> | 2 | VOID |
> +---+-------------------------+
> | 3 | IPv4 |
> +---+-------------------------+
> | 4 | TCP |
> +---+-------------------------+
> | 5 | VOID |
> +---+-------------------------+
> | 6 | VOID |
> +---+-------------------------+
>
> The above example shows how meta items do not affect packet data matching
> items, as long as those remain stacked properly. The resulting matching
> pattern is identical to "TCPv4 as L4".
>
> +----------------+
> | UDPv6 anywhere |
> +===+============+
> | 0 | IPv6 |
> +---+------------+
> | 1 | UDP |
> +---+------------+
>
> If supported by the PMD, omitting one or several protocol layers at the
> bottom of the stack as in the above example (missing an Ethernet
> specification) enables hardware to look anywhere in packets.
It would be good if the common code can give it as Ethernet, IPV6, UDP
to PMD(to avoid common code duplication across PMDs)
>
> It is unspecified whether the payload of supported encapsulations
> (e.g. VXLAN inner packet) is matched by such a pattern, which may apply to
> inner, outer or both packets.
a separate flow type enumeration may fix that problem. like "Inner-IPV6"
mentioned above.
>
> +---------------------+
> | Invalid, missing L3 |
> +===+=================+
> | 0 | Ethernet |
> +---+-----------------+
> | 1 | UDP |
> +---+-----------------+
>
> The above pattern is invalid due to a missing L3 specification between L2
> and L4. It is only allowed at the bottom and at the top of the stack.
>
> ``SIGNATURE``
> ^^^^^^^^^^^^^
>
> Requests hash-based signature dispatching for this rule.
>
> Considering this is a global setting on devices that support it, all
> subsequent filter rules may have to be created with it as well.
Can you describe the use case for this and how its different from
existing rte_eth devel RSS settings.
>
> - Only ``spec`` needs to be defined, ``mask`` is ignored.
>
> +--------------------+
> | SIGNATURE |
> +==========+=========+
> | ``spec`` | TBD |
> +----------+---------+
> | ``mask`` | ignored |
> +----------+---------+
>
>
> ``ETH``
> ^^^^^^^
>
> Matches an Ethernet header.
>
> - ``dst``: destination MAC.
> - ``src``: source MAC.
> - ``type``: EtherType.
> - ``tags``: number of 802.1Q/ad tags defined.
> - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one:
>
> - ``tpid``: Tag protocol identifier.
> - ``tci``: Tag control information.
Find below the other L2 layer attributes are useful in HW classification,
- HiGig headers
- DSA Headers
- MPLS
May be we need to intrdouce a separate flow type with spec to add the support. Right?
Jerin
More information about the dev
mailing list