d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

ethdev: clarify flow API pattern items and actions

Browse Source 
Although pattern items and actions examples end with "and so on", these
lists include all existing definitions and as a result are updated almost
every time new types are added. This is cumbersome and pointless.

This patch also synchronizes Doxygen and external API documentation wording
with a slight clarification regarding meta pattern items.

No fundamental API change.

Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
This commit is contained in:
Adrien Mazarguil 2018-04-25 17:27:41 +02:00 committed by Ferruh Yigit
parent 7eb312e342
commit 9f995def55
2 changed files with 21 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/guides/prog_guide/rte_flow.rst
View File

@ -186,12 +186,13 @@ Pattern item
Pattern items fall in two categories:
- Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4,
IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE, ESP and so on), usually
associated with a specification structure.
- Matching protocol headers and packet data, usually associated with a
specification structure. These must be stacked in the same order as the
protocol layers to match inside packets, starting from the lowest.
- Matching meta-data or affecting pattern processing (END, VOID, INVERT, PF,
VF, PORT and so on), often without a specification structure.
- Matching meta-data or affecting pattern processing, often without a
specification structure. Since they do not match packet contents, their
position in the list is usually not relevant.
Item specification structures are used to match specific values among
protocol fields (or item properties). Documentation describes for each item
@ -1001,15 +1002,13 @@ to a flow rule. That list is not ordered.
They fall in three categories:
- Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
processing matched packets by subsequent flow rules, unless overridden
with PASSTHRU.
- Terminating actions that prevent processing matched packets by subsequent
flow rules, unless overridden with PASSTHRU.
- Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for
additional processing by subsequent flow rules.
- Non-terminating actions that leave matched packets up for additional
processing by subsequent flow rules.
- Other non-terminating meta actions that do not affect the fate of packets
(END, VOID, MARK, FLAG, COUNT, SECURITY).
- Other non-terminating meta actions that do not affect the fate of packets.
When several actions are combined in a flow rule, they should all have
different types (e.g. dropping a packet twice is not possible).

23
lib/librte_ether/rte_flow.h
View File

@ -78,15 +78,13 @@ struct rte_flow_attr {
*
* Pattern items fall in two categories:
*
* - Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4,
* IPV6, ICMP, UDP, TCP, SCTP, VXLAN and so on), usually associated with a
* - Matching protocol headers and packet data, usually associated with a
* specification structure. These must be stacked in the same order as the
* protocol layers to match, starting from the lowest.
* protocol layers to match inside packets, starting from the lowest.
*
* - Matching meta-data or affecting pattern processing (END, VOID, INVERT,
* PF, VF, PORT and so on), often without a specification structure. Since
* they do not match packet contents, these can be specified anywhere
* within item lists without affecting others.
* - Matching meta-data or affecting pattern processing, often without a
* specification structure. Since they do not match packet contents, their
* position in the list is usually not relevant.
*
* See the description of individual types for more information. Those
* marked with [META] fall into the second category.
@ -865,15 +863,14 @@ struct rte_flow_item {
*
* They fall in three categories:
*
* - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
* processing matched packets by subsequent flow rules, unless overridden
* with PASSTHRU.
* - Terminating actions that prevent processing matched packets by
* subsequent flow rules, unless overridden with PASSTHRU.
*
* - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
* for additional processing by subsequent flow rules.
* - Non terminating actions that leave matched packets up for additional
* processing by subsequent flow rules.
*
* - Other non terminating meta actions that do not affect the fate of
* packets (END, VOID, MARK, FLAG, COUNT).
* packets.
*
* When several actions are combined in a flow rule, they should all have
* different types (e.g. dropping a packet twice is not possible).