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