]>
Commit | Line | Data |
---|---|---|
9f95a23c | 1 | .. SPDX-License-Identifier: BSD-3-Clause |
11fdf7f2 | 2 | Copyright 2016 6WIND S.A. |
9f95a23c | 3 | Copyright 2016 Mellanox Technologies, Ltd |
11fdf7f2 TL |
4 | |
5 | Generic flow API (rte_flow) | |
6 | =========================== | |
7 | ||
8 | Overview | |
9 | -------- | |
10 | ||
11 | This API provides a generic means to configure hardware to match specific | |
12 | ingress or egress traffic, alter its fate and query related counters | |
13 | according to any number of user-defined rules. | |
14 | ||
15 | It is named *rte_flow* after the prefix used for all its symbols, and is | |
16 | defined in ``rte_flow.h``. | |
17 | ||
18 | - Matching can be performed on packet data (protocol headers, payload) and | |
19 | properties (e.g. associated physical port, virtual device function ID). | |
20 | ||
21 | - Possible operations include dropping traffic, diverting it to specific | |
22 | queues, to virtual/physical device functions or ports, performing tunnel | |
23 | offloads, adding marks and so on. | |
24 | ||
25 | It is slightly higher-level than the legacy filtering framework which it | |
26 | encompasses and supersedes (including all functions and filter types) in | |
27 | order to expose a single interface with an unambiguous behavior that is | |
28 | common to all poll-mode drivers (PMDs). | |
29 | ||
11fdf7f2 TL |
30 | Flow rule |
31 | --------- | |
32 | ||
33 | Description | |
34 | ~~~~~~~~~~~ | |
35 | ||
36 | A flow rule is the combination of attributes with a matching pattern and a | |
37 | list of actions. Flow rules form the basis of this API. | |
38 | ||
39 | Flow rules can have several distinct actions (such as counting, | |
40 | encapsulating, decapsulating before redirecting packets to a particular | |
41 | queue, etc.), instead of relying on several rules to achieve this and having | |
42 | applications deal with hardware implementation details regarding their | |
43 | order. | |
44 | ||
45 | Support for different priority levels on a rule basis is provided, for | |
46 | example in order to force a more specific rule to come before a more generic | |
47 | one for packets matched by both. However hardware support for more than a | |
48 | single priority level cannot be guaranteed. When supported, the number of | |
49 | available priority levels is usually low, which is why they can also be | |
50 | implemented in software by PMDs (e.g. missing priority levels may be | |
51 | emulated by reordering rules). | |
52 | ||
53 | In order to remain as hardware-agnostic as possible, by default all rules | |
54 | are considered to have the same priority, which means that the order between | |
55 | overlapping rules (when a packet is matched by several filters) is | |
56 | undefined. | |
57 | ||
58 | PMDs may refuse to create overlapping rules at a given priority level when | |
59 | they can be detected (e.g. if a pattern matches an existing filter). | |
60 | ||
61 | Thus predictable results for a given priority level can only be achieved | |
62 | with non-overlapping rules, using perfect matching on all protocol layers. | |
63 | ||
64 | Flow rules can also be grouped, the flow rule priority is specific to the | |
9f95a23c TL |
65 | group they belong to. All flow rules in a given group are thus processed within |
66 | the context of that group. Groups are not linked by default, so the logical | |
67 | hierarchy of groups must be explicitly defined by flow rules themselves in each | |
68 | group using the JUMP action to define the next group to redirect too. Only flow | |
69 | rules defined in the default group 0 are guarantee to be matched against, this | |
70 | makes group 0 the origin of any group hierarchy defined by an application. | |
11fdf7f2 TL |
71 | |
72 | Support for multiple actions per rule may be implemented internally on top | |
73 | of non-default hardware priorities, as a result both features may not be | |
74 | simultaneously available to applications. | |
75 | ||
76 | Considering that allowed pattern/actions combinations cannot be known in | |
77 | advance and would result in an impractically large number of capabilities to | |
78 | expose, a method is provided to validate a given rule from the current | |
79 | device configuration state. | |
80 | ||
81 | This enables applications to check if the rule types they need is supported | |
82 | at initialization time, before starting their data path. This method can be | |
83 | used anytime, its only requirement being that the resources needed by a rule | |
84 | should exist (e.g. a target RX queue should be configured first). | |
85 | ||
86 | Each defined rule is associated with an opaque handle managed by the PMD, | |
87 | applications are responsible for keeping it. These can be used for queries | |
88 | and rules management, such as retrieving counters or other data and | |
89 | destroying them. | |
90 | ||
91 | To avoid resource leaks on the PMD side, handles must be explicitly | |
92 | destroyed by the application before releasing associated resources such as | |
93 | queues and ports. | |
94 | ||
95 | The following sections cover: | |
96 | ||
97 | - **Attributes** (represented by ``struct rte_flow_attr``): properties of a | |
98 | flow rule such as its direction (ingress or egress) and priority. | |
99 | ||
100 | - **Pattern item** (represented by ``struct rte_flow_item``): part of a | |
101 | matching pattern that either matches specific packet data or traffic | |
102 | properties. It can also describe properties of the pattern itself, such as | |
103 | inverted matching. | |
104 | ||
105 | - **Matching pattern**: traffic properties to look for, a combination of any | |
106 | number of items. | |
107 | ||
108 | - **Actions** (represented by ``struct rte_flow_action``): operations to | |
109 | perform whenever a packet is matched by a pattern. | |
110 | ||
111 | Attributes | |
112 | ~~~~~~~~~~ | |
113 | ||
114 | Attribute: Group | |
115 | ^^^^^^^^^^^^^^^^ | |
116 | ||
9f95a23c TL |
117 | Flow rules can be grouped by assigning them a common group number. Groups |
118 | allow a logical hierarchy of flow rule groups (tables) to be defined. These | |
119 | groups can be supported virtually in the PMD or in the physical device. | |
120 | Group 0 is the default group and this is the only group which flows are | |
121 | guarantee to matched against, all subsequent groups can only be reached by | |
122 | way of the JUMP action from a matched flow rule. | |
11fdf7f2 TL |
123 | |
124 | Although optional, applications are encouraged to group similar rules as | |
125 | much as possible to fully take advantage of hardware capabilities | |
126 | (e.g. optimized matching) and work around limitations (e.g. a single pattern | |
9f95a23c TL |
127 | type possibly allowed in a given group), while being aware that the groups |
128 | hierarchies must be programmed explicitly. | |
11fdf7f2 TL |
129 | |
130 | Note that support for more than a single group is not guaranteed. | |
131 | ||
132 | Attribute: Priority | |
133 | ^^^^^^^^^^^^^^^^^^^ | |
134 | ||
9f95a23c | 135 | A priority level can be assigned to a flow rule, lower values |
11fdf7f2 TL |
136 | denote higher priority, with 0 as the maximum. |
137 | ||
9f95a23c | 138 | Priority levels are arbitrary and up to the application, they do |
11fdf7f2 TL |
139 | not need to be contiguous nor start from 0, however the maximum number |
140 | varies between devices and may be affected by existing flow rules. | |
141 | ||
9f95a23c TL |
142 | A flow which matches multiple rules in the same group will always matched by |
143 | the rule with the highest priority in that group. | |
144 | ||
11fdf7f2 TL |
145 | If a packet is matched by several rules of a given group for a given |
146 | priority level, the outcome is undefined. It can take any path, may be | |
147 | duplicated or even cause unrecoverable errors. | |
148 | ||
149 | Note that support for more than a single priority level is not guaranteed. | |
150 | ||
151 | Attribute: Traffic direction | |
152 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
153 | ||
9f95a23c TL |
154 | Flow rule patterns apply to inbound and/or outbound traffic. |
155 | ||
156 | In the context of this API, **ingress** and **egress** respectively stand | |
157 | for **inbound** and **outbound** based on the standpoint of the application | |
158 | creating a flow rule. | |
159 | ||
160 | There are no exceptions to this definition. | |
11fdf7f2 TL |
161 | |
162 | Several pattern items and actions are valid and can be used in both | |
163 | directions. At least one direction must be specified. | |
164 | ||
165 | Specifying both directions at once for a given rule is not recommended but | |
166 | may be valid in a few cases (e.g. shared counters). | |
167 | ||
9f95a23c TL |
168 | Attribute: Transfer |
169 | ^^^^^^^^^^^^^^^^^^^ | |
170 | ||
171 | Instead of simply matching the properties of traffic as it would appear on a | |
172 | given DPDK port ID, enabling this attribute transfers a flow rule to the | |
173 | lowest possible level of any device endpoints found in the pattern. | |
174 | ||
175 | When supported, this effectively enables an application to reroute traffic | |
176 | not necessarily intended for it (e.g. coming from or addressed to different | |
177 | physical ports, VFs or applications) at the device level. | |
178 | ||
179 | It complements the behavior of some pattern items such as `Item: PHY_PORT`_ | |
180 | and is meaningless without them. | |
181 | ||
182 | When transferring flow rules, **ingress** and **egress** attributes | |
183 | (`Attribute: Traffic direction`_) keep their original meaning, as if | |
184 | processing traffic emitted or received by the application. | |
185 | ||
11fdf7f2 TL |
186 | Pattern item |
187 | ~~~~~~~~~~~~ | |
188 | ||
189 | Pattern items fall in two categories: | |
190 | ||
9f95a23c TL |
191 | - Matching protocol headers and packet data, usually associated with a |
192 | specification structure. These must be stacked in the same order as the | |
193 | protocol layers to match inside packets, starting from the lowest. | |
11fdf7f2 | 194 | |
9f95a23c TL |
195 | - Matching meta-data or affecting pattern processing, often without a |
196 | specification structure. Since they do not match packet contents, their | |
197 | position in the list is usually not relevant. | |
11fdf7f2 TL |
198 | |
199 | Item specification structures are used to match specific values among | |
200 | protocol fields (or item properties). Documentation describes for each item | |
201 | whether they are associated with one and their type name if so. | |
202 | ||
203 | Up to three structures of the same type can be set for a given item: | |
204 | ||
205 | - ``spec``: values to match (e.g. a given IPv4 address). | |
206 | ||
207 | - ``last``: upper bound for an inclusive range with corresponding fields in | |
208 | ``spec``. | |
209 | ||
210 | - ``mask``: bit-mask applied to both ``spec`` and ``last`` whose purpose is | |
211 | to distinguish the values to take into account and/or partially mask them | |
212 | out (e.g. in order to match an IPv4 address prefix). | |
213 | ||
214 | Usage restrictions and expected behavior: | |
215 | ||
216 | - Setting either ``mask`` or ``last`` without ``spec`` is an error. | |
217 | ||
218 | - Field values in ``last`` which are either 0 or equal to the corresponding | |
219 | values in ``spec`` are ignored; they do not generate a range. Nonzero | |
220 | values lower than those in ``spec`` are not supported. | |
221 | ||
222 | - Setting ``spec`` and optionally ``last`` without ``mask`` causes the PMD | |
223 | to use the default mask defined for that item (defined as | |
224 | ``rte_flow_item_{name}_mask`` constants). | |
225 | ||
226 | - Not setting any of them (assuming item type allows it) is equivalent to | |
227 | providing an empty (zeroed) ``mask`` for broad (nonspecific) matching. | |
228 | ||
229 | - ``mask`` is a simple bit-mask applied before interpreting the contents of | |
230 | ``spec`` and ``last``, which may yield unexpected results if not used | |
231 | carefully. For example, if for an IPv4 address field, ``spec`` provides | |
232 | *10.1.2.3*, ``last`` provides *10.3.4.5* and ``mask`` provides | |
233 | *255.255.0.0*, the effective range becomes *10.1.0.0* to *10.3.255.255*. | |
234 | ||
235 | Example of an item specification matching an Ethernet header: | |
236 | ||
237 | .. _table_rte_flow_pattern_item_example: | |
238 | ||
239 | .. table:: Ethernet item | |
240 | ||
241 | +----------+----------+--------------------+ | |
242 | | Field | Subfield | Value | | |
243 | +==========+==========+====================+ | |
244 | | ``spec`` | ``src`` | ``00:01:02:03:04`` | | |
245 | | +----------+--------------------+ | |
246 | | | ``dst`` | ``00:2a:66:00:01`` | | |
247 | | +----------+--------------------+ | |
248 | | | ``type`` | ``0x22aa`` | | |
249 | +----------+----------+--------------------+ | |
250 | | ``last`` | unspecified | | |
251 | +----------+----------+--------------------+ | |
252 | | ``mask`` | ``src`` | ``00:ff:ff:ff:00`` | | |
253 | | +----------+--------------------+ | |
254 | | | ``dst`` | ``00:00:00:00:ff`` | | |
255 | | +----------+--------------------+ | |
256 | | | ``type`` | ``0x0000`` | | |
257 | +----------+----------+--------------------+ | |
258 | ||
259 | Non-masked bits stand for any value (shown as ``?`` below), Ethernet headers | |
260 | with the following properties are thus matched: | |
261 | ||
262 | - ``src``: ``??:01:02:03:??`` | |
263 | - ``dst``: ``??:??:??:??:01`` | |
264 | - ``type``: ``0x????`` | |
265 | ||
266 | Matching pattern | |
267 | ~~~~~~~~~~~~~~~~ | |
268 | ||
269 | A pattern is formed by stacking items starting from the lowest protocol | |
270 | layer to match. This stacking restriction does not apply to meta items which | |
271 | can be placed anywhere in the stack without affecting the meaning of the | |
272 | resulting pattern. | |
273 | ||
274 | Patterns are terminated by END items. | |
275 | ||
276 | Examples: | |
277 | ||
278 | .. _table_rte_flow_tcpv4_as_l4: | |
279 | ||
280 | .. table:: TCPv4 as L4 | |
281 | ||
282 | +-------+----------+ | |
283 | | Index | Item | | |
284 | +=======+==========+ | |
285 | | 0 | Ethernet | | |
286 | +-------+----------+ | |
287 | | 1 | IPv4 | | |
288 | +-------+----------+ | |
289 | | 2 | TCP | | |
290 | +-------+----------+ | |
291 | | 3 | END | | |
292 | +-------+----------+ | |
293 | ||
294 | | | |
295 | ||
296 | .. _table_rte_flow_tcpv6_in_vxlan: | |
297 | ||
298 | .. table:: TCPv6 in VXLAN | |
299 | ||
300 | +-------+------------+ | |
301 | | Index | Item | | |
302 | +=======+============+ | |
303 | | 0 | Ethernet | | |
304 | +-------+------------+ | |
305 | | 1 | IPv4 | | |
306 | +-------+------------+ | |
307 | | 2 | UDP | | |
308 | +-------+------------+ | |
309 | | 3 | VXLAN | | |
310 | +-------+------------+ | |
311 | | 4 | Ethernet | | |
312 | +-------+------------+ | |
313 | | 5 | IPv6 | | |
314 | +-------+------------+ | |
315 | | 6 | TCP | | |
316 | +-------+------------+ | |
317 | | 7 | END | | |
318 | +-------+------------+ | |
319 | ||
320 | | | |
321 | ||
322 | .. _table_rte_flow_tcpv4_as_l4_meta: | |
323 | ||
324 | .. table:: TCPv4 as L4 with meta items | |
325 | ||
326 | +-------+----------+ | |
327 | | Index | Item | | |
328 | +=======+==========+ | |
329 | | 0 | VOID | | |
330 | +-------+----------+ | |
331 | | 1 | Ethernet | | |
332 | +-------+----------+ | |
333 | | 2 | VOID | | |
334 | +-------+----------+ | |
335 | | 3 | IPv4 | | |
336 | +-------+----------+ | |
337 | | 4 | TCP | | |
338 | +-------+----------+ | |
339 | | 5 | VOID | | |
340 | +-------+----------+ | |
341 | | 6 | VOID | | |
342 | +-------+----------+ | |
343 | | 7 | END | | |
344 | +-------+----------+ | |
345 | ||
346 | The above example shows how meta items do not affect packet data matching | |
347 | items, as long as those remain stacked properly. The resulting matching | |
348 | pattern is identical to "TCPv4 as L4". | |
349 | ||
350 | .. _table_rte_flow_udpv6_anywhere: | |
351 | ||
352 | .. table:: UDPv6 anywhere | |
353 | ||
354 | +-------+------+ | |
355 | | Index | Item | | |
356 | +=======+======+ | |
357 | | 0 | IPv6 | | |
358 | +-------+------+ | |
359 | | 1 | UDP | | |
360 | +-------+------+ | |
361 | | 2 | END | | |
362 | +-------+------+ | |
363 | ||
364 | If supported by the PMD, omitting one or several protocol layers at the | |
365 | bottom of the stack as in the above example (missing an Ethernet | |
366 | specification) enables looking up anywhere in packets. | |
367 | ||
368 | It is unspecified whether the payload of supported encapsulations | |
369 | (e.g. VXLAN payload) is matched by such a pattern, which may apply to inner, | |
370 | outer or both packets. | |
371 | ||
372 | .. _table_rte_flow_invalid_l3: | |
373 | ||
374 | .. table:: Invalid, missing L3 | |
375 | ||
376 | +-------+----------+ | |
377 | | Index | Item | | |
378 | +=======+==========+ | |
379 | | 0 | Ethernet | | |
380 | +-------+----------+ | |
381 | | 1 | UDP | | |
382 | +-------+----------+ | |
383 | | 2 | END | | |
384 | +-------+----------+ | |
385 | ||
386 | The above pattern is invalid due to a missing L3 specification between L2 | |
387 | (Ethernet) and L4 (UDP). Doing so is only allowed at the bottom and at the | |
388 | top of the stack. | |
389 | ||
390 | Meta item types | |
391 | ~~~~~~~~~~~~~~~ | |
392 | ||
393 | They match meta-data or affect pattern processing instead of matching packet | |
394 | data directly, most of them do not need a specification structure. This | |
395 | particularity allows them to be specified anywhere in the stack without | |
396 | causing any side effect. | |
397 | ||
398 | Item: ``END`` | |
399 | ^^^^^^^^^^^^^ | |
400 | ||
401 | End marker for item lists. Prevents further processing of items, thereby | |
402 | ending the pattern. | |
403 | ||
404 | - Its numeric value is 0 for convenience. | |
405 | - PMD support is mandatory. | |
406 | - ``spec``, ``last`` and ``mask`` are ignored. | |
407 | ||
408 | .. _table_rte_flow_item_end: | |
409 | ||
410 | .. table:: END | |
411 | ||
412 | +----------+---------+ | |
413 | | Field | Value | | |
414 | +==========+=========+ | |
415 | | ``spec`` | ignored | | |
416 | +----------+---------+ | |
417 | | ``last`` | ignored | | |
418 | +----------+---------+ | |
419 | | ``mask`` | ignored | | |
420 | +----------+---------+ | |
421 | ||
422 | Item: ``VOID`` | |
423 | ^^^^^^^^^^^^^^ | |
424 | ||
425 | Used as a placeholder for convenience. It is ignored and simply discarded by | |
426 | PMDs. | |
427 | ||
428 | - PMD support is mandatory. | |
429 | - ``spec``, ``last`` and ``mask`` are ignored. | |
430 | ||
431 | .. _table_rte_flow_item_void: | |
432 | ||
433 | .. table:: VOID | |
434 | ||
435 | +----------+---------+ | |
436 | | Field | Value | | |
437 | +==========+=========+ | |
438 | | ``spec`` | ignored | | |
439 | +----------+---------+ | |
440 | | ``last`` | ignored | | |
441 | +----------+---------+ | |
442 | | ``mask`` | ignored | | |
443 | +----------+---------+ | |
444 | ||
445 | One usage example for this type is generating rules that share a common | |
446 | prefix quickly without reallocating memory, only by updating item types: | |
447 | ||
448 | .. _table_rte_flow_item_void_example: | |
449 | ||
450 | .. table:: TCP, UDP or ICMP as L4 | |
451 | ||
452 | +-------+--------------------+ | |
453 | | Index | Item | | |
454 | +=======+====================+ | |
455 | | 0 | Ethernet | | |
456 | +-------+--------------------+ | |
457 | | 1 | IPv4 | | |
458 | +-------+------+------+------+ | |
459 | | 2 | UDP | VOID | VOID | | |
460 | +-------+------+------+------+ | |
461 | | 3 | VOID | TCP | VOID | | |
462 | +-------+------+------+------+ | |
463 | | 4 | VOID | VOID | ICMP | | |
464 | +-------+------+------+------+ | |
465 | | 5 | END | | |
466 | +-------+--------------------+ | |
467 | ||
468 | Item: ``INVERT`` | |
469 | ^^^^^^^^^^^^^^^^ | |
470 | ||
471 | Inverted matching, i.e. process packets that do not match the pattern. | |
472 | ||
473 | - ``spec``, ``last`` and ``mask`` are ignored. | |
474 | ||
475 | .. _table_rte_flow_item_invert: | |
476 | ||
477 | .. table:: INVERT | |
478 | ||
479 | +----------+---------+ | |
480 | | Field | Value | | |
481 | +==========+=========+ | |
482 | | ``spec`` | ignored | | |
483 | +----------+---------+ | |
484 | | ``last`` | ignored | | |
485 | +----------+---------+ | |
486 | | ``mask`` | ignored | | |
487 | +----------+---------+ | |
488 | ||
489 | Usage example, matching non-TCPv4 packets only: | |
490 | ||
491 | .. _table_rte_flow_item_invert_example: | |
492 | ||
493 | .. table:: Anything but TCPv4 | |
494 | ||
495 | +-------+----------+ | |
496 | | Index | Item | | |
497 | +=======+==========+ | |
498 | | 0 | INVERT | | |
499 | +-------+----------+ | |
500 | | 1 | Ethernet | | |
501 | +-------+----------+ | |
502 | | 2 | IPv4 | | |
503 | +-------+----------+ | |
504 | | 3 | TCP | | |
505 | +-------+----------+ | |
506 | | 4 | END | | |
507 | +-------+----------+ | |
508 | ||
509 | Item: ``PF`` | |
510 | ^^^^^^^^^^^^ | |
511 | ||
9f95a23c TL |
512 | Matches traffic originating from (ingress) or going to (egress) the physical |
513 | function of the current device. | |
11fdf7f2 | 514 | |
9f95a23c TL |
515 | If supported, should work even if the physical function is not managed by |
516 | the application and thus not associated with a DPDK port ID. | |
11fdf7f2 | 517 | |
11fdf7f2 TL |
518 | - Can be combined with any number of `Item: VF`_ to match both PF and VF |
519 | traffic. | |
520 | - ``spec``, ``last`` and ``mask`` must not be set. | |
521 | ||
522 | .. _table_rte_flow_item_pf: | |
523 | ||
524 | .. table:: PF | |
525 | ||
526 | +----------+-------+ | |
527 | | Field | Value | | |
528 | +==========+=======+ | |
529 | | ``spec`` | unset | | |
530 | +----------+-------+ | |
531 | | ``last`` | unset | | |
532 | +----------+-------+ | |
533 | | ``mask`` | unset | | |
534 | +----------+-------+ | |
535 | ||
536 | Item: ``VF`` | |
537 | ^^^^^^^^^^^^ | |
538 | ||
9f95a23c TL |
539 | Matches traffic originating from (ingress) or going to (egress) a given |
540 | virtual function of the current device. | |
541 | ||
542 | If supported, should work even if the virtual function is not managed by the | |
543 | application and thus not associated with a DPDK port ID. | |
11fdf7f2 | 544 | |
9f95a23c TL |
545 | Note this pattern item does not match VF representors traffic which, as |
546 | separate entities, should be addressed through their own DPDK port IDs. | |
11fdf7f2 | 547 | |
11fdf7f2 TL |
548 | - Can be specified multiple times to match traffic addressed to several VF |
549 | IDs. | |
550 | - Can be combined with a PF item to match both PF and VF traffic. | |
551 | - Default ``mask`` matches any VF ID. | |
552 | ||
553 | .. _table_rte_flow_item_vf: | |
554 | ||
555 | .. table:: VF | |
556 | ||
557 | +----------+----------+---------------------------+ | |
558 | | Field | Subfield | Value | | |
559 | +==========+==========+===========================+ | |
560 | | ``spec`` | ``id`` | destination VF ID | | |
561 | +----------+----------+---------------------------+ | |
562 | | ``last`` | ``id`` | upper range value | | |
563 | +----------+----------+---------------------------+ | |
564 | | ``mask`` | ``id`` | zeroed to match any VF ID | | |
565 | +----------+----------+---------------------------+ | |
566 | ||
9f95a23c TL |
567 | Item: ``PHY_PORT`` |
568 | ^^^^^^^^^^^^^^^^^^ | |
11fdf7f2 | 569 | |
9f95a23c TL |
570 | Matches traffic originating from (ingress) or going to (egress) a physical |
571 | port of the underlying device. | |
11fdf7f2 | 572 | |
9f95a23c TL |
573 | The first PHY_PORT item overrides the physical port normally associated with |
574 | the specified DPDK input port (port_id). This item can be provided several | |
575 | times to match additional physical ports. | |
11fdf7f2 TL |
576 | |
577 | Note that physical ports are not necessarily tied to DPDK input ports | |
578 | (port_id) when those are not under DPDK control. Possible values are | |
579 | specific to each device, they are not necessarily indexed from zero and may | |
580 | not be contiguous. | |
581 | ||
582 | As a device property, the list of allowed values as well as the value | |
583 | associated with a port_id should be retrieved by other means. | |
584 | ||
585 | - Default ``mask`` matches any port index. | |
586 | ||
9f95a23c | 587 | .. _table_rte_flow_item_phy_port: |
11fdf7f2 | 588 | |
9f95a23c | 589 | .. table:: PHY_PORT |
11fdf7f2 TL |
590 | |
591 | +----------+-----------+--------------------------------+ | |
592 | | Field | Subfield | Value | | |
593 | +==========+===========+================================+ | |
594 | | ``spec`` | ``index`` | physical port index | | |
595 | +----------+-----------+--------------------------------+ | |
596 | | ``last`` | ``index`` | upper range value | | |
597 | +----------+-----------+--------------------------------+ | |
598 | | ``mask`` | ``index`` | zeroed to match any port index | | |
599 | +----------+-----------+--------------------------------+ | |
600 | ||
9f95a23c TL |
601 | Item: ``PORT_ID`` |
602 | ^^^^^^^^^^^^^^^^^ | |
603 | ||
604 | Matches traffic originating from (ingress) or going to (egress) a given DPDK | |
605 | port ID. | |
606 | ||
607 | Normally only supported if the port ID in question is known by the | |
608 | underlying PMD and related to the device the flow rule is created against. | |
609 | ||
610 | This must not be confused with `Item: PHY_PORT`_ which refers to the | |
611 | physical port of a device, whereas `Item: PORT_ID`_ refers to a ``struct | |
612 | rte_eth_dev`` object on the application side (also known as "port | |
613 | representor" depending on the kind of underlying device). | |
614 | ||
615 | - Default ``mask`` matches the specified DPDK port ID. | |
616 | ||
617 | .. _table_rte_flow_item_port_id: | |
618 | ||
619 | .. table:: PORT_ID | |
620 | ||
621 | +----------+----------+-----------------------------+ | |
622 | | Field | Subfield | Value | | |
623 | +==========+==========+=============================+ | |
624 | | ``spec`` | ``id`` | DPDK port ID | | |
625 | +----------+----------+-----------------------------+ | |
626 | | ``last`` | ``id`` | upper range value | | |
627 | +----------+----------+-----------------------------+ | |
628 | | ``mask`` | ``id`` | zeroed to match any port ID | | |
629 | +----------+----------+-----------------------------+ | |
630 | ||
631 | Item: ``MARK`` | |
632 | ^^^^^^^^^^^^^^ | |
633 | ||
634 | Matches an arbitrary integer value which was set using the ``MARK`` action in | |
635 | a previously matched rule. | |
636 | ||
637 | This item can only specified once as a match criteria as the ``MARK`` action can | |
638 | only be specified once in a flow action. | |
639 | ||
640 | Note the value of MARK field is arbitrary and application defined. | |
641 | ||
642 | Depending on the underlying implementation the MARK item may be supported on | |
643 | the physical device, with virtual groups in the PMD or not at all. | |
644 | ||
645 | - Default ``mask`` matches any integer value. | |
646 | ||
647 | .. _table_rte_flow_item_mark: | |
648 | ||
649 | .. table:: MARK | |
650 | ||
651 | +----------+----------+---------------------------+ | |
652 | | Field | Subfield | Value | | |
653 | +==========+==========+===========================+ | |
654 | | ``spec`` | ``id`` | integer value | | |
655 | +----------+--------------------------------------+ | |
656 | | ``last`` | ``id`` | upper range value | | |
657 | +----------+----------+---------------------------+ | |
658 | | ``mask`` | ``id`` | zeroed to match any value | | |
659 | +----------+----------+---------------------------+ | |
660 | ||
11fdf7f2 TL |
661 | Data matching item types |
662 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
663 | ||
664 | Most of these are basically protocol header definitions with associated | |
665 | bit-masks. They must be specified (stacked) from lowest to highest protocol | |
666 | layer to form a matching pattern. | |
667 | ||
668 | The following list is not exhaustive, new protocols will be added in the | |
669 | future. | |
670 | ||
671 | Item: ``ANY`` | |
672 | ^^^^^^^^^^^^^ | |
673 | ||
674 | Matches any protocol in place of the current layer, a single ANY may also | |
675 | stand for several protocol layers. | |
676 | ||
677 | This is usually specified as the first pattern item when looking for a | |
678 | protocol anywhere in a packet. | |
679 | ||
680 | - Default ``mask`` stands for any number of layers. | |
681 | ||
682 | .. _table_rte_flow_item_any: | |
683 | ||
684 | .. table:: ANY | |
685 | ||
686 | +----------+----------+--------------------------------------+ | |
687 | | Field | Subfield | Value | | |
688 | +==========+==========+======================================+ | |
689 | | ``spec`` | ``num`` | number of layers covered | | |
690 | +----------+----------+--------------------------------------+ | |
691 | | ``last`` | ``num`` | upper range value | | |
692 | +----------+----------+--------------------------------------+ | |
693 | | ``mask`` | ``num`` | zeroed to cover any number of layers | | |
694 | +----------+----------+--------------------------------------+ | |
695 | ||
696 | Example for VXLAN TCP payload matching regardless of outer L3 (IPv4 or IPv6) | |
697 | and L4 (UDP) both matched by the first ANY specification, and inner L3 (IPv4 | |
698 | or IPv6) matched by the second ANY specification: | |
699 | ||
700 | .. _table_rte_flow_item_any_example: | |
701 | ||
702 | .. table:: TCP in VXLAN with wildcards | |
703 | ||
704 | +-------+------+----------+----------+-------+ | |
705 | | Index | Item | Field | Subfield | Value | | |
706 | +=======+======+==========+==========+=======+ | |
707 | | 0 | Ethernet | | |
708 | +-------+------+----------+----------+-------+ | |
709 | | 1 | ANY | ``spec`` | ``num`` | 2 | | |
710 | +-------+------+----------+----------+-------+ | |
711 | | 2 | VXLAN | | |
712 | +-------+------------------------------------+ | |
713 | | 3 | Ethernet | | |
714 | +-------+------+----------+----------+-------+ | |
715 | | 4 | ANY | ``spec`` | ``num`` | 1 | | |
716 | +-------+------+----------+----------+-------+ | |
717 | | 5 | TCP | | |
718 | +-------+------------------------------------+ | |
719 | | 6 | END | | |
720 | +-------+------------------------------------+ | |
721 | ||
722 | Item: ``RAW`` | |
723 | ^^^^^^^^^^^^^ | |
724 | ||
725 | Matches a byte string of a given length at a given offset. | |
726 | ||
727 | Offset is either absolute (using the start of the packet) or relative to the | |
728 | end of the previous matched item in the stack, in which case negative values | |
729 | are allowed. | |
730 | ||
731 | If search is enabled, offset is used as the starting point. The search area | |
732 | can be delimited by setting limit to a nonzero value, which is the maximum | |
733 | number of bytes after offset where the pattern may start. | |
734 | ||
735 | Matching a zero-length pattern is allowed, doing so resets the relative | |
736 | offset for subsequent items. | |
737 | ||
738 | - This type does not support ranges (``last`` field). | |
739 | - Default ``mask`` matches all fields exactly. | |
740 | ||
741 | .. _table_rte_flow_item_raw: | |
742 | ||
743 | .. table:: RAW | |
744 | ||
745 | +----------+--------------+-------------------------------------------------+ | |
746 | | Field | Subfield | Value | | |
747 | +==========+==============+=================================================+ | |
748 | | ``spec`` | ``relative`` | look for pattern after the previous item | | |
749 | | +--------------+-------------------------------------------------+ | |
750 | | | ``search`` | search pattern from offset (see also ``limit``) | | |
751 | | +--------------+-------------------------------------------------+ | |
752 | | | ``reserved`` | reserved, must be set to zero | | |
753 | | +--------------+-------------------------------------------------+ | |
754 | | | ``offset`` | absolute or relative offset for ``pattern`` | | |
755 | | +--------------+-------------------------------------------------+ | |
756 | | | ``limit`` | search area limit for start of ``pattern`` | | |
757 | | +--------------+-------------------------------------------------+ | |
758 | | | ``length`` | ``pattern`` length | | |
759 | | +--------------+-------------------------------------------------+ | |
760 | | | ``pattern`` | byte string to look for | | |
761 | +----------+--------------+-------------------------------------------------+ | |
762 | | ``last`` | if specified, either all 0 or with the same values as ``spec`` | | |
763 | +----------+----------------------------------------------------------------+ | |
764 | | ``mask`` | bit-mask applied to ``spec`` values with usual behavior | | |
765 | +----------+----------------------------------------------------------------+ | |
766 | ||
767 | Example pattern looking for several strings at various offsets of a UDP | |
768 | payload, using combined RAW items: | |
769 | ||
770 | .. _table_rte_flow_item_raw_example: | |
771 | ||
772 | .. table:: UDP payload matching | |
773 | ||
774 | +-------+------+----------+--------------+-------+ | |
775 | | Index | Item | Field | Subfield | Value | | |
776 | +=======+======+==========+==============+=======+ | |
777 | | 0 | Ethernet | | |
778 | +-------+----------------------------------------+ | |
779 | | 1 | IPv4 | | |
780 | +-------+----------------------------------------+ | |
781 | | 2 | UDP | | |
782 | +-------+------+----------+--------------+-------+ | |
783 | | 3 | RAW | ``spec`` | ``relative`` | 1 | | |
784 | | | | +--------------+-------+ | |
785 | | | | | ``search`` | 1 | | |
786 | | | | +--------------+-------+ | |
787 | | | | | ``offset`` | 10 | | |
788 | | | | +--------------+-------+ | |
789 | | | | | ``limit`` | 0 | | |
790 | | | | +--------------+-------+ | |
791 | | | | | ``length`` | 3 | | |
792 | | | | +--------------+-------+ | |
793 | | | | | ``pattern`` | "foo" | | |
794 | +-------+------+----------+--------------+-------+ | |
795 | | 4 | RAW | ``spec`` | ``relative`` | 1 | | |
796 | | | | +--------------+-------+ | |
797 | | | | | ``search`` | 0 | | |
798 | | | | +--------------+-------+ | |
799 | | | | | ``offset`` | 20 | | |
800 | | | | +--------------+-------+ | |
801 | | | | | ``limit`` | 0 | | |
802 | | | | +--------------+-------+ | |
803 | | | | | ``length`` | 3 | | |
804 | | | | +--------------+-------+ | |
805 | | | | | ``pattern`` | "bar" | | |
806 | +-------+------+----------+--------------+-------+ | |
807 | | 5 | RAW | ``spec`` | ``relative`` | 1 | | |
808 | | | | +--------------+-------+ | |
809 | | | | | ``search`` | 0 | | |
810 | | | | +--------------+-------+ | |
811 | | | | | ``offset`` | -29 | | |
812 | | | | +--------------+-------+ | |
813 | | | | | ``limit`` | 0 | | |
814 | | | | +--------------+-------+ | |
815 | | | | | ``length`` | 3 | | |
816 | | | | +--------------+-------+ | |
817 | | | | | ``pattern`` | "baz" | | |
818 | +-------+------+----------+--------------+-------+ | |
819 | | 6 | END | | |
820 | +-------+----------------------------------------+ | |
821 | ||
822 | This translates to: | |
823 | ||
824 | - Locate "foo" at least 10 bytes deep inside UDP payload. | |
825 | - Locate "bar" after "foo" plus 20 bytes. | |
826 | - Locate "baz" after "bar" minus 29 bytes. | |
827 | ||
828 | Such a packet may be represented as follows (not to scale):: | |
829 | ||
830 | 0 >= 10 B == 20 B | |
831 | | |<--------->| |<--------->| | |
832 | | | | | | | |
833 | |-----|------|-----|-----|-----|-----|-----------|-----|------| | |
834 | | ETH | IPv4 | UDP | ... | baz | foo | ......... | bar | .... | | |
835 | |-----|------|-----|-----|-----|-----|-----------|-----|------| | |
836 | | | | |
837 | |<--------------------------->| | |
838 | == 29 B | |
839 | ||
840 | Note that matching subsequent pattern items would resume after "baz", not | |
841 | "bar" since matching is always performed after the previous item of the | |
842 | stack. | |
843 | ||
844 | Item: ``ETH`` | |
845 | ^^^^^^^^^^^^^ | |
846 | ||
847 | Matches an Ethernet header. | |
848 | ||
9f95a23c TL |
849 | The ``type`` field either stands for "EtherType" or "TPID" when followed by |
850 | so-called layer 2.5 pattern items such as ``RTE_FLOW_ITEM_TYPE_VLAN``. In | |
851 | the latter case, ``type`` refers to that of the outer header, with the inner | |
852 | EtherType/TPID provided by the subsequent pattern item. This is the same | |
853 | order as on the wire. | |
854 | ||
11fdf7f2 TL |
855 | - ``dst``: destination MAC. |
856 | - ``src``: source MAC. | |
9f95a23c | 857 | - ``type``: EtherType or TPID. |
11fdf7f2 TL |
858 | - Default ``mask`` matches destination and source addresses only. |
859 | ||
860 | Item: ``VLAN`` | |
861 | ^^^^^^^^^^^^^^ | |
862 | ||
863 | Matches an 802.1Q/ad VLAN tag. | |
864 | ||
9f95a23c TL |
865 | The corresponding standard outer EtherType (TPID) values are |
866 | ``ETHER_TYPE_VLAN`` or ``ETHER_TYPE_QINQ``. It can be overridden by the | |
867 | preceding pattern item. | |
868 | ||
11fdf7f2 | 869 | - ``tci``: tag control information. |
9f95a23c TL |
870 | - ``inner_type``: inner EtherType or TPID. |
871 | - Default ``mask`` matches the VID part of TCI only (lower 12 bits). | |
11fdf7f2 TL |
872 | |
873 | Item: ``IPV4`` | |
874 | ^^^^^^^^^^^^^^ | |
875 | ||
876 | Matches an IPv4 header. | |
877 | ||
878 | Note: IPv4 options are handled by dedicated pattern items. | |
879 | ||
880 | - ``hdr``: IPv4 header definition (``rte_ip.h``). | |
881 | - Default ``mask`` matches source and destination addresses only. | |
882 | ||
883 | Item: ``IPV6`` | |
884 | ^^^^^^^^^^^^^^ | |
885 | ||
886 | Matches an IPv6 header. | |
887 | ||
9f95a23c TL |
888 | Note: IPv6 options are handled by dedicated pattern items, see `Item: |
889 | IPV6_EXT`_. | |
11fdf7f2 TL |
890 | |
891 | - ``hdr``: IPv6 header definition (``rte_ip.h``). | |
892 | - Default ``mask`` matches source and destination addresses only. | |
893 | ||
894 | Item: ``ICMP`` | |
895 | ^^^^^^^^^^^^^^ | |
896 | ||
897 | Matches an ICMP header. | |
898 | ||
899 | - ``hdr``: ICMP header definition (``rte_icmp.h``). | |
900 | - Default ``mask`` matches ICMP type and code only. | |
901 | ||
902 | Item: ``UDP`` | |
903 | ^^^^^^^^^^^^^ | |
904 | ||
905 | Matches a UDP header. | |
906 | ||
907 | - ``hdr``: UDP header definition (``rte_udp.h``). | |
908 | - Default ``mask`` matches source and destination ports only. | |
909 | ||
910 | Item: ``TCP`` | |
911 | ^^^^^^^^^^^^^ | |
912 | ||
913 | Matches a TCP header. | |
914 | ||
915 | - ``hdr``: TCP header definition (``rte_tcp.h``). | |
916 | - Default ``mask`` matches source and destination ports only. | |
917 | ||
918 | Item: ``SCTP`` | |
919 | ^^^^^^^^^^^^^^ | |
920 | ||
921 | Matches a SCTP header. | |
922 | ||
923 | - ``hdr``: SCTP header definition (``rte_sctp.h``). | |
924 | - Default ``mask`` matches source and destination ports only. | |
925 | ||
926 | Item: ``VXLAN`` | |
927 | ^^^^^^^^^^^^^^^ | |
928 | ||
929 | Matches a VXLAN header (RFC 7348). | |
930 | ||
931 | - ``flags``: normally 0x08 (I flag). | |
932 | - ``rsvd0``: reserved, normally 0x000000. | |
933 | - ``vni``: VXLAN network identifier. | |
934 | - ``rsvd1``: reserved, normally 0x00. | |
935 | - Default ``mask`` matches VNI only. | |
936 | ||
937 | Item: ``E_TAG`` | |
938 | ^^^^^^^^^^^^^^^ | |
939 | ||
940 | Matches an IEEE 802.1BR E-Tag header. | |
941 | ||
9f95a23c TL |
942 | The corresponding standard outer EtherType (TPID) value is |
943 | ``ETHER_TYPE_ETAG``. It can be overridden by the preceding pattern item. | |
944 | ||
11fdf7f2 TL |
945 | - ``epcp_edei_in_ecid_b``: E-Tag control information (E-TCI), E-PCP (3b), |
946 | E-DEI (1b), ingress E-CID base (12b). | |
947 | - ``rsvd_grp_ecid_b``: reserved (2b), GRP (2b), E-CID base (12b). | |
948 | - ``in_ecid_e``: ingress E-CID ext. | |
949 | - ``ecid_e``: E-CID ext. | |
9f95a23c | 950 | - ``inner_type``: inner EtherType or TPID. |
11fdf7f2 TL |
951 | - Default ``mask`` simultaneously matches GRP and E-CID base. |
952 | ||
953 | Item: ``NVGRE`` | |
954 | ^^^^^^^^^^^^^^^ | |
955 | ||
956 | Matches a NVGRE header (RFC 7637). | |
957 | ||
958 | - ``c_k_s_rsvd0_ver``: checksum (1b), undefined (1b), key bit (1b), | |
959 | sequence number (1b), reserved 0 (9b), version (3b). This field must have | |
960 | value 0x2000 according to RFC 7637. | |
961 | - ``protocol``: protocol type (0x6558). | |
962 | - ``tni``: virtual subnet ID. | |
963 | - ``flow_id``: flow ID. | |
964 | - Default ``mask`` matches TNI only. | |
965 | ||
966 | Item: ``MPLS`` | |
967 | ^^^^^^^^^^^^^^ | |
968 | ||
969 | Matches a MPLS header. | |
970 | ||
971 | - ``label_tc_s_ttl``: label, TC, Bottom of Stack and TTL. | |
972 | - Default ``mask`` matches label only. | |
973 | ||
974 | Item: ``GRE`` | |
9f95a23c | 975 | ^^^^^^^^^^^^^ |
11fdf7f2 TL |
976 | |
977 | Matches a GRE header. | |
978 | ||
979 | - ``c_rsvd0_ver``: checksum, reserved 0 and version. | |
980 | - ``protocol``: protocol type. | |
981 | - Default ``mask`` matches protocol only. | |
982 | ||
9f95a23c TL |
983 | Item: ``FUZZY`` |
984 | ^^^^^^^^^^^^^^^ | |
985 | ||
986 | Fuzzy pattern match, expect faster than default. | |
987 | ||
988 | This is for device that support fuzzy match option. Usually a fuzzy match is | |
989 | fast but the cost is accuracy. i.e. Signature Match only match pattern's hash | |
990 | value, but it is possible two different patterns have the same hash value. | |
991 | ||
992 | Matching accuracy level can be configured by threshold. Driver can divide the | |
993 | range of threshold and map to different accuracy levels that device support. | |
994 | ||
995 | Threshold 0 means perfect match (no fuzziness), while threshold 0xffffffff | |
996 | means fuzziest match. | |
997 | ||
998 | .. _table_rte_flow_item_fuzzy: | |
999 | ||
1000 | .. table:: FUZZY | |
1001 | ||
1002 | +----------+---------------+--------------------------------------------------+ | |
1003 | | Field | Subfield | Value | | |
1004 | +==========+===============+==================================================+ | |
1005 | | ``spec`` | ``threshold`` | 0 as perfect match, 0xffffffff as fuzziest match | | |
1006 | +----------+---------------+--------------------------------------------------+ | |
1007 | | ``last`` | ``threshold`` | upper range value | | |
1008 | +----------+---------------+--------------------------------------------------+ | |
1009 | | ``mask`` | ``threshold`` | bit-mask apply to "spec" and "last" | | |
1010 | +----------+---------------+--------------------------------------------------+ | |
1011 | ||
1012 | Usage example, fuzzy match a TCPv4 packets: | |
1013 | ||
1014 | .. _table_rte_flow_item_fuzzy_example: | |
1015 | ||
1016 | .. table:: Fuzzy matching | |
1017 | ||
1018 | +-------+----------+ | |
1019 | | Index | Item | | |
1020 | +=======+==========+ | |
1021 | | 0 | FUZZY | | |
1022 | +-------+----------+ | |
1023 | | 1 | Ethernet | | |
1024 | +-------+----------+ | |
1025 | | 2 | IPv4 | | |
1026 | +-------+----------+ | |
1027 | | 3 | TCP | | |
1028 | +-------+----------+ | |
1029 | | 4 | END | | |
1030 | +-------+----------+ | |
1031 | ||
1032 | Item: ``GTP``, ``GTPC``, ``GTPU`` | |
1033 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1034 | ||
1035 | Matches a GTPv1 header. | |
1036 | ||
1037 | Note: GTP, GTPC and GTPU use the same structure. GTPC and GTPU item | |
1038 | are defined for a user-friendly API when creating GTP-C and GTP-U | |
1039 | flow rules. | |
1040 | ||
1041 | - ``v_pt_rsv_flags``: version (3b), protocol type (1b), reserved (1b), | |
1042 | extension header flag (1b), sequence number flag (1b), N-PDU number | |
1043 | flag (1b). | |
1044 | - ``msg_type``: message type. | |
1045 | - ``msg_len``: message length. | |
1046 | - ``teid``: tunnel endpoint identifier. | |
1047 | - Default ``mask`` matches teid only. | |
1048 | ||
1049 | Item: ``ESP`` | |
1050 | ^^^^^^^^^^^^^ | |
1051 | ||
1052 | Matches an ESP header. | |
1053 | ||
1054 | - ``hdr``: ESP header definition (``rte_esp.h``). | |
1055 | - Default ``mask`` matches SPI only. | |
1056 | ||
1057 | Item: ``GENEVE`` | |
1058 | ^^^^^^^^^^^^^^^^ | |
1059 | ||
1060 | Matches a GENEVE header. | |
1061 | ||
1062 | - ``ver_opt_len_o_c_rsvd0``: version (2b), length of the options fields (6b), | |
1063 | OAM packet (1b), critical options present (1b), reserved 0 (6b). | |
1064 | - ``protocol``: protocol type. | |
1065 | - ``vni``: virtual network identifier. | |
1066 | - ``rsvd1``: reserved, normally 0x00. | |
1067 | - Default ``mask`` matches VNI only. | |
1068 | ||
1069 | Item: ``VXLAN-GPE`` | |
1070 | ^^^^^^^^^^^^^^^^^^^ | |
1071 | ||
1072 | Matches a VXLAN-GPE header (draft-ietf-nvo3-vxlan-gpe-05). | |
1073 | ||
1074 | - ``flags``: normally 0x0C (I and P flags). | |
1075 | - ``rsvd0``: reserved, normally 0x0000. | |
1076 | - ``protocol``: protocol type. | |
1077 | - ``vni``: VXLAN network identifier. | |
1078 | - ``rsvd1``: reserved, normally 0x00. | |
1079 | - Default ``mask`` matches VNI only. | |
1080 | ||
1081 | Item: ``ARP_ETH_IPV4`` | |
1082 | ^^^^^^^^^^^^^^^^^^^^^^ | |
1083 | ||
1084 | Matches an ARP header for Ethernet/IPv4. | |
1085 | ||
1086 | - ``hdr``: hardware type, normally 1. | |
1087 | - ``pro``: protocol type, normally 0x0800. | |
1088 | - ``hln``: hardware address length, normally 6. | |
1089 | - ``pln``: protocol address length, normally 4. | |
1090 | - ``op``: opcode (1 for request, 2 for reply). | |
1091 | - ``sha``: sender hardware address. | |
1092 | - ``spa``: sender IPv4 address. | |
1093 | - ``tha``: target hardware address. | |
1094 | - ``tpa``: target IPv4 address. | |
1095 | - Default ``mask`` matches SHA, SPA, THA and TPA. | |
1096 | ||
1097 | Item: ``IPV6_EXT`` | |
1098 | ^^^^^^^^^^^^^^^^^^ | |
1099 | ||
1100 | Matches the presence of any IPv6 extension header. | |
1101 | ||
1102 | - ``next_hdr``: next header. | |
1103 | - Default ``mask`` matches ``next_hdr``. | |
1104 | ||
1105 | Normally preceded by any of: | |
1106 | ||
1107 | - `Item: IPV6`_ | |
1108 | - `Item: IPV6_EXT`_ | |
1109 | ||
1110 | Item: ``ICMP6`` | |
1111 | ^^^^^^^^^^^^^^^ | |
1112 | ||
1113 | Matches any ICMPv6 header. | |
1114 | ||
1115 | - ``type``: ICMPv6 type. | |
1116 | - ``code``: ICMPv6 code. | |
1117 | - ``checksum``: ICMPv6 checksum. | |
1118 | - Default ``mask`` matches ``type`` and ``code``. | |
1119 | ||
1120 | Item: ``ICMP6_ND_NS`` | |
1121 | ^^^^^^^^^^^^^^^^^^^^^ | |
1122 | ||
1123 | Matches an ICMPv6 neighbor discovery solicitation. | |
1124 | ||
1125 | - ``type``: ICMPv6 type, normally 135. | |
1126 | - ``code``: ICMPv6 code, normally 0. | |
1127 | - ``checksum``: ICMPv6 checksum. | |
1128 | - ``reserved``: reserved, normally 0. | |
1129 | - ``target_addr``: target address. | |
1130 | - Default ``mask`` matches target address only. | |
1131 | ||
1132 | Item: ``ICMP6_ND_NA`` | |
1133 | ^^^^^^^^^^^^^^^^^^^^^ | |
1134 | ||
1135 | Matches an ICMPv6 neighbor discovery advertisement. | |
1136 | ||
1137 | - ``type``: ICMPv6 type, normally 136. | |
1138 | - ``code``: ICMPv6 code, normally 0. | |
1139 | - ``checksum``: ICMPv6 checksum. | |
1140 | - ``rso_reserved``: route flag (1b), solicited flag (1b), override flag | |
1141 | (1b), reserved (29b). | |
1142 | - ``target_addr``: target address. | |
1143 | - Default ``mask`` matches target address only. | |
1144 | ||
1145 | Item: ``ICMP6_ND_OPT`` | |
1146 | ^^^^^^^^^^^^^^^^^^^^^^ | |
1147 | ||
1148 | Matches the presence of any ICMPv6 neighbor discovery option. | |
1149 | ||
1150 | - ``type``: ND option type. | |
1151 | - ``length``: ND option length. | |
1152 | - Default ``mask`` matches type only. | |
1153 | ||
1154 | Normally preceded by any of: | |
1155 | ||
1156 | - `Item: ICMP6_ND_NA`_ | |
1157 | - `Item: ICMP6_ND_NS`_ | |
1158 | - `Item: ICMP6_ND_OPT`_ | |
1159 | ||
1160 | Item: ``ICMP6_ND_OPT_SLA_ETH`` | |
1161 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1162 | ||
1163 | Matches an ICMPv6 neighbor discovery source Ethernet link-layer address | |
1164 | option. | |
1165 | ||
1166 | - ``type``: ND option type, normally 1. | |
1167 | - ``length``: ND option length, normally 1. | |
1168 | - ``sla``: source Ethernet LLA. | |
1169 | - Default ``mask`` matches source link-layer address only. | |
1170 | ||
1171 | Normally preceded by any of: | |
1172 | ||
1173 | - `Item: ICMP6_ND_NA`_ | |
1174 | - `Item: ICMP6_ND_OPT`_ | |
1175 | ||
1176 | Item: ``ICMP6_ND_OPT_TLA_ETH`` | |
1177 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1178 | ||
1179 | Matches an ICMPv6 neighbor discovery target Ethernet link-layer address | |
1180 | option. | |
1181 | ||
1182 | - ``type``: ND option type, normally 2. | |
1183 | - ``length``: ND option length, normally 1. | |
1184 | - ``tla``: target Ethernet LLA. | |
1185 | - Default ``mask`` matches target link-layer address only. | |
1186 | ||
1187 | Normally preceded by any of: | |
1188 | ||
1189 | - `Item: ICMP6_ND_NS`_ | |
1190 | - `Item: ICMP6_ND_OPT`_ | |
1191 | ||
1192 | Item: ``META`` | |
1193 | ^^^^^^^^^^^^^^ | |
1194 | ||
1195 | Matches an application specific 32 bit metadata item. | |
1196 | ||
1197 | - Default ``mask`` matches the specified metadata value. | |
1198 | ||
1199 | .. _table_rte_flow_item_meta: | |
1200 | ||
1201 | .. table:: META | |
1202 | ||
1203 | +----------+----------+---------------------------------------+ | |
1204 | | Field | Subfield | Value | | |
1205 | +==========+==========+=======================================+ | |
1206 | | ``spec`` | ``data`` | 32 bit metadata value | | |
1207 | +----------+--------------------------------------------------+ | |
1208 | | ``last`` | ``data`` | upper range value | | |
1209 | +----------+----------+---------------------------------------+ | |
1210 | | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" | | |
1211 | +----------+----------+---------------------------------------+ | |
1212 | ||
11fdf7f2 TL |
1213 | Actions |
1214 | ~~~~~~~ | |
1215 | ||
1216 | Each possible action is represented by a type. Some have associated | |
9f95a23c TL |
1217 | configuration structures. Several actions combined in a list can be assigned |
1218 | to a flow rule and are performed in order. | |
11fdf7f2 TL |
1219 | |
1220 | They fall in three categories: | |
1221 | ||
9f95a23c TL |
1222 | - Actions that modify the fate of matching traffic, for instance by dropping |
1223 | or assigning it a specific destination. | |
11fdf7f2 | 1224 | |
9f95a23c TL |
1225 | - Actions that modify matching traffic contents or its properties. This |
1226 | includes adding/removing encapsulation, encryption, compression and marks. | |
11fdf7f2 | 1227 | |
9f95a23c TL |
1228 | - Actions related to the flow rule itself, such as updating counters or |
1229 | making it non-terminating. | |
11fdf7f2 | 1230 | |
9f95a23c TL |
1231 | Flow rules being terminating by default, not specifying any action of the |
1232 | fate kind results in undefined behavior. This applies to both ingress and | |
1233 | egress. | |
11fdf7f2 | 1234 | |
9f95a23c | 1235 | PASSTHRU, when supported, makes a flow rule non-terminating. |
11fdf7f2 TL |
1236 | |
1237 | Like matching patterns, action lists are terminated by END items. | |
1238 | ||
11fdf7f2 TL |
1239 | Example of action that redirects packets to queue index 10: |
1240 | ||
1241 | .. _table_rte_flow_action_example: | |
1242 | ||
1243 | .. table:: Queue action | |
1244 | ||
1245 | +-----------+-------+ | |
1246 | | Field | Value | | |
1247 | +===========+=======+ | |
1248 | | ``index`` | 10 | | |
1249 | +-----------+-------+ | |
1250 | ||
9f95a23c | 1251 | Actions are performed in list order: |
11fdf7f2 | 1252 | |
9f95a23c | 1253 | .. _table_rte_flow_count_then_drop: |
11fdf7f2 | 1254 | |
9f95a23c | 1255 | .. table:: Count then drop |
11fdf7f2 TL |
1256 | |
1257 | +-------+--------+ | |
1258 | | Index | Action | | |
1259 | +=======+========+ | |
1260 | | 0 | COUNT | | |
1261 | +-------+--------+ | |
1262 | | 1 | DROP | | |
1263 | +-------+--------+ | |
1264 | | 2 | END | | |
1265 | +-------+--------+ | |
1266 | ||
1267 | | | |
1268 | ||
1269 | .. _table_rte_flow_mark_count_redirect: | |
1270 | ||
9f95a23c TL |
1271 | .. table:: Mark, count then redirect |
1272 | ||
1273 | +-------+--------+------------+-------+ | |
1274 | | Index | Action | Field | Value | | |
1275 | +=======+========+============+=======+ | |
1276 | | 0 | MARK | ``mark`` | 0x2a | | |
1277 | +-------+--------+------------+-------+ | |
1278 | | 1 | COUNT | ``shared`` | 0 | | |
1279 | | | +------------+-------+ | |
1280 | | | | ``id`` | 0 | | |
1281 | +-------+--------+------------+-------+ | |
1282 | | 2 | QUEUE | ``queue`` | 10 | | |
1283 | +-------+--------+------------+-------+ | |
1284 | | 3 | END | | |
1285 | +-------+-----------------------------+ | |
11fdf7f2 TL |
1286 | |
1287 | | | |
1288 | ||
1289 | .. _table_rte_flow_redirect_queue_5: | |
1290 | ||
1291 | .. table:: Redirect to queue 5 | |
1292 | ||
1293 | +-------+--------+-----------+-------+ | |
1294 | | Index | Action | Field | Value | | |
1295 | +=======+========+===========+=======+ | |
1296 | | 0 | DROP | | |
1297 | +-------+--------+-----------+-------+ | |
1298 | | 1 | QUEUE | ``queue`` | 5 | | |
1299 | +-------+--------+-----------+-------+ | |
1300 | | 2 | END | | |
1301 | +-------+----------------------------+ | |
1302 | ||
9f95a23c TL |
1303 | In the above example, while DROP and QUEUE must be performed in order, both |
1304 | have to happen before reaching END. Only QUEUE has a visible effect. | |
1305 | ||
1306 | Note that such a list may be thought as ambiguous and rejected on that | |
1307 | basis. | |
11fdf7f2 | 1308 | |
9f95a23c | 1309 | .. _table_rte_flow_redirect_queue_5_3: |
11fdf7f2 | 1310 | |
9f95a23c | 1311 | .. table:: Redirect to queues 5 and 3 |
11fdf7f2 TL |
1312 | |
1313 | +-------+--------+-----------+-------+ | |
1314 | | Index | Action | Field | Value | | |
1315 | +=======+========+===========+=======+ | |
1316 | | 0 | QUEUE | ``queue`` | 5 | | |
1317 | +-------+--------+-----------+-------+ | |
1318 | | 1 | VOID | | |
1319 | +-------+--------+-----------+-------+ | |
1320 | | 2 | QUEUE | ``queue`` | 3 | | |
1321 | +-------+--------+-----------+-------+ | |
1322 | | 3 | END | | |
1323 | +-------+----------------------------+ | |
1324 | ||
9f95a23c TL |
1325 | As previously described, all actions must be taken into account. This |
1326 | effectively duplicates traffic to both queues. The above example also shows | |
1327 | that VOID is ignored. | |
11fdf7f2 TL |
1328 | |
1329 | Action types | |
1330 | ~~~~~~~~~~~~ | |
1331 | ||
1332 | Common action types are described in this section. Like pattern item types, | |
1333 | this list is not exhaustive as new actions will be added in the future. | |
1334 | ||
1335 | Action: ``END`` | |
1336 | ^^^^^^^^^^^^^^^ | |
1337 | ||
1338 | End marker for action lists. Prevents further processing of actions, thereby | |
1339 | ending the list. | |
1340 | ||
1341 | - Its numeric value is 0 for convenience. | |
1342 | - PMD support is mandatory. | |
1343 | - No configurable properties. | |
1344 | ||
1345 | .. _table_rte_flow_action_end: | |
1346 | ||
1347 | .. table:: END | |
1348 | ||
1349 | +---------------+ | |
1350 | | Field | | |
1351 | +===============+ | |
1352 | | no properties | | |
1353 | +---------------+ | |
1354 | ||
1355 | Action: ``VOID`` | |
1356 | ^^^^^^^^^^^^^^^^ | |
1357 | ||
1358 | Used as a placeholder for convenience. It is ignored and simply discarded by | |
1359 | PMDs. | |
1360 | ||
1361 | - PMD support is mandatory. | |
1362 | - No configurable properties. | |
1363 | ||
1364 | .. _table_rte_flow_action_void: | |
1365 | ||
1366 | .. table:: VOID | |
1367 | ||
1368 | +---------------+ | |
1369 | | Field | | |
1370 | +===============+ | |
1371 | | no properties | | |
1372 | +---------------+ | |
1373 | ||
1374 | Action: ``PASSTHRU`` | |
1375 | ^^^^^^^^^^^^^^^^^^^^ | |
1376 | ||
9f95a23c TL |
1377 | Leaves traffic up for additional processing by subsequent flow rules; makes |
1378 | a flow rule non-terminating. | |
11fdf7f2 TL |
1379 | |
1380 | - No configurable properties. | |
1381 | ||
1382 | .. _table_rte_flow_action_passthru: | |
1383 | ||
1384 | .. table:: PASSTHRU | |
1385 | ||
1386 | +---------------+ | |
1387 | | Field | | |
1388 | +===============+ | |
1389 | | no properties | | |
1390 | +---------------+ | |
1391 | ||
1392 | Example to copy a packet to a queue and continue processing by subsequent | |
1393 | flow rules: | |
1394 | ||
1395 | .. _table_rte_flow_action_passthru_example: | |
1396 | ||
1397 | .. table:: Copy to queue 8 | |
1398 | ||
1399 | +-------+--------+-----------+-------+ | |
1400 | | Index | Action | Field | Value | | |
1401 | +=======+========+===========+=======+ | |
1402 | | 0 | PASSTHRU | | |
1403 | +-------+--------+-----------+-------+ | |
1404 | | 1 | QUEUE | ``queue`` | 8 | | |
1405 | +-------+--------+-----------+-------+ | |
1406 | | 2 | END | | |
1407 | +-------+----------------------------+ | |
1408 | ||
9f95a23c TL |
1409 | Action: ``JUMP`` |
1410 | ^^^^^^^^^^^^^^^^ | |
1411 | ||
1412 | Redirects packets to a group on the current device. | |
1413 | ||
1414 | In a hierarchy of groups, which can be used to represent physical or logical | |
1415 | flow group/tables on the device, this action redirects the matched flow to | |
1416 | the specified group on that device. | |
1417 | ||
1418 | If a matched flow is redirected to a table which doesn't contain a matching | |
1419 | rule for that flow then the behavior is undefined and the resulting behavior | |
1420 | is up to the specific device. Best practice when using groups would be define | |
1421 | a default flow rule for each group which a defines the default actions in that | |
1422 | group so a consistent behavior is defined. | |
1423 | ||
1424 | Defining an action for matched flow in a group to jump to a group which is | |
1425 | higher in the group hierarchy may not be supported by physical devices, | |
1426 | depending on how groups are mapped to the physical devices. In the | |
1427 | definitions of jump actions, applications should be aware that it may be | |
1428 | possible to define flow rules which trigger an undefined behavior causing | |
1429 | flows to loop between groups. | |
1430 | ||
1431 | .. _table_rte_flow_action_jump: | |
1432 | ||
1433 | .. table:: JUMP | |
1434 | ||
1435 | +-----------+------------------------------+ | |
1436 | | Field | Value | | |
1437 | +===========+==============================+ | |
1438 | | ``group`` | Group to redirect packets to | | |
1439 | +-----------+------------------------------+ | |
1440 | ||
11fdf7f2 TL |
1441 | Action: ``MARK`` |
1442 | ^^^^^^^^^^^^^^^^ | |
1443 | ||
1444 | Attaches an integer value to packets and sets ``PKT_RX_FDIR`` and | |
1445 | ``PKT_RX_FDIR_ID`` mbuf flags. | |
1446 | ||
1447 | This value is arbitrary and application-defined. Maximum allowed value | |
1448 | depends on the underlying implementation. It is returned in the | |
1449 | ``hash.fdir.hi`` mbuf field. | |
1450 | ||
1451 | .. _table_rte_flow_action_mark: | |
1452 | ||
1453 | .. table:: MARK | |
1454 | ||
1455 | +--------+--------------------------------------+ | |
1456 | | Field | Value | | |
1457 | +========+======================================+ | |
1458 | | ``id`` | integer value to return with packets | | |
1459 | +--------+--------------------------------------+ | |
1460 | ||
1461 | Action: ``FLAG`` | |
1462 | ^^^^^^^^^^^^^^^^ | |
1463 | ||
1464 | Flags packets. Similar to `Action: MARK`_ without a specific value; only | |
1465 | sets the ``PKT_RX_FDIR`` mbuf flag. | |
1466 | ||
1467 | - No configurable properties. | |
1468 | ||
1469 | .. _table_rte_flow_action_flag: | |
1470 | ||
1471 | .. table:: FLAG | |
1472 | ||
1473 | +---------------+ | |
1474 | | Field | | |
1475 | +===============+ | |
1476 | | no properties | | |
1477 | +---------------+ | |
1478 | ||
1479 | Action: ``QUEUE`` | |
1480 | ^^^^^^^^^^^^^^^^^ | |
1481 | ||
1482 | Assigns packets to a given queue index. | |
1483 | ||
11fdf7f2 TL |
1484 | .. _table_rte_flow_action_queue: |
1485 | ||
1486 | .. table:: QUEUE | |
1487 | ||
1488 | +-----------+--------------------+ | |
1489 | | Field | Value | | |
1490 | +===========+====================+ | |
1491 | | ``index`` | queue index to use | | |
1492 | +-----------+--------------------+ | |
1493 | ||
1494 | Action: ``DROP`` | |
1495 | ^^^^^^^^^^^^^^^^ | |
1496 | ||
1497 | Drop packets. | |
1498 | ||
1499 | - No configurable properties. | |
11fdf7f2 TL |
1500 | |
1501 | .. _table_rte_flow_action_drop: | |
1502 | ||
1503 | .. table:: DROP | |
1504 | ||
1505 | +---------------+ | |
1506 | | Field | | |
1507 | +===============+ | |
1508 | | no properties | | |
1509 | +---------------+ | |
1510 | ||
1511 | Action: ``COUNT`` | |
1512 | ^^^^^^^^^^^^^^^^^ | |
1513 | ||
9f95a23c | 1514 | Adds a counter action to a matched flow. |
11fdf7f2 | 1515 | |
9f95a23c TL |
1516 | If more than one count action is specified in a single flow rule, then each |
1517 | action must specify a unique id. | |
1518 | ||
1519 | Counters can be retrieved and reset through ``rte_flow_query()``, see | |
11fdf7f2 TL |
1520 | ``struct rte_flow_query_count``. |
1521 | ||
9f95a23c TL |
1522 | The shared flag indicates whether the counter is unique to the flow rule the |
1523 | action is specified with, or whether it is a shared counter. | |
1524 | ||
1525 | For a count action with the shared flag set, then then a global device | |
1526 | namespace is assumed for the counter id, so that any matched flow rules using | |
1527 | a count action with the same counter id on the same port will contribute to | |
1528 | that counter. | |
1529 | ||
1530 | For ports within the same switch domain then the counter id namespace extends | |
1531 | to all ports within that switch domain. | |
11fdf7f2 TL |
1532 | |
1533 | .. _table_rte_flow_action_count: | |
1534 | ||
1535 | .. table:: COUNT | |
1536 | ||
9f95a23c TL |
1537 | +------------+---------------------+ |
1538 | | Field | Value | | |
1539 | +============+=====================+ | |
1540 | | ``shared`` | shared counter flag | | |
1541 | +------------+---------------------+ | |
1542 | | ``id`` | counter id | | |
1543 | +------------+---------------------+ | |
11fdf7f2 TL |
1544 | |
1545 | Query structure to retrieve and reset flow rule counters: | |
1546 | ||
1547 | .. _table_rte_flow_query_count: | |
1548 | ||
1549 | .. table:: COUNT query | |
1550 | ||
1551 | +---------------+-----+-----------------------------------+ | |
1552 | | Field | I/O | Value | | |
1553 | +===============+=====+===================================+ | |
1554 | | ``reset`` | in | reset counter after query | | |
1555 | +---------------+-----+-----------------------------------+ | |
1556 | | ``hits_set`` | out | ``hits`` field is set | | |
1557 | +---------------+-----+-----------------------------------+ | |
1558 | | ``bytes_set`` | out | ``bytes`` field is set | | |
1559 | +---------------+-----+-----------------------------------+ | |
1560 | | ``hits`` | out | number of hits for this rule | | |
1561 | +---------------+-----+-----------------------------------+ | |
1562 | | ``bytes`` | out | number of bytes through this rule | | |
1563 | +---------------+-----+-----------------------------------+ | |
1564 | ||
9f95a23c | 1565 | Action: ``RSS`` |
11fdf7f2 TL |
1566 | ^^^^^^^^^^^^^^^ |
1567 | ||
9f95a23c TL |
1568 | Similar to QUEUE, except RSS is additionally performed on packets to spread |
1569 | them among several queues according to the provided parameters. | |
11fdf7f2 | 1570 | |
9f95a23c TL |
1571 | Unlike global RSS settings used by other DPDK APIs, unsetting the ``types`` |
1572 | field does not disable RSS in a flow rule. Doing so instead requests safe | |
1573 | unspecified "best-effort" settings from the underlying PMD, which depending | |
1574 | on the flow rule, may result in anything ranging from empty (single queue) | |
1575 | to all-inclusive RSS. | |
11fdf7f2 | 1576 | |
9f95a23c TL |
1577 | Note: RSS hash result is stored in the ``hash.rss`` mbuf field which |
1578 | overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` | |
1579 | field only, both can be requested simultaneously. | |
11fdf7f2 | 1580 | |
9f95a23c | 1581 | Also, regarding packet encapsulation ``level``: |
11fdf7f2 | 1582 | |
9f95a23c TL |
1583 | - ``0`` requests the default behavior. Depending on the packet type, it can |
1584 | mean outermost, innermost, anything in between or even no RSS. | |
11fdf7f2 | 1585 | |
9f95a23c TL |
1586 | It basically stands for the innermost encapsulation level RSS can be |
1587 | performed on according to PMD and device capabilities. | |
11fdf7f2 | 1588 | |
9f95a23c TL |
1589 | - ``1`` requests RSS to be performed on the outermost packet encapsulation |
1590 | level. | |
11fdf7f2 | 1591 | |
9f95a23c TL |
1592 | - ``2`` and subsequent values request RSS to be performed on the specified |
1593 | inner packet encapsulation level, from outermost to innermost (lower to | |
1594 | higher values). | |
11fdf7f2 | 1595 | |
9f95a23c | 1596 | Values other than ``0`` are not necessarily supported. |
11fdf7f2 | 1597 | |
9f95a23c TL |
1598 | Requesting a specific RSS level on unrecognized traffic results in undefined |
1599 | behavior. For predictable results, it is recommended to make the flow rule | |
1600 | pattern match packet headers up to the requested encapsulation level so that | |
1601 | only matching traffic goes through. | |
11fdf7f2 TL |
1602 | |
1603 | .. _table_rte_flow_action_rss: | |
1604 | ||
1605 | .. table:: RSS | |
1606 | ||
9f95a23c TL |
1607 | +---------------+---------------------------------------------+ |
1608 | | Field | Value | | |
1609 | +===============+=============================================+ | |
1610 | | ``func`` | RSS hash function to apply | | |
1611 | +---------------+---------------------------------------------+ | |
1612 | | ``level`` | encapsulation level for ``types`` | | |
1613 | +---------------+---------------------------------------------+ | |
1614 | | ``types`` | specific RSS hash types (see ``ETH_RSS_*``) | | |
1615 | +---------------+---------------------------------------------+ | |
1616 | | ``key_len`` | hash key length in bytes | | |
1617 | +---------------+---------------------------------------------+ | |
1618 | | ``queue_num`` | number of entries in ``queue`` | | |
1619 | +---------------+---------------------------------------------+ | |
1620 | | ``key`` | hash key | | |
1621 | +---------------+---------------------------------------------+ | |
1622 | | ``queue`` | queue indices to use | | |
1623 | +---------------+---------------------------------------------+ | |
11fdf7f2 TL |
1624 | |
1625 | Action: ``PF`` | |
1626 | ^^^^^^^^^^^^^^ | |
1627 | ||
9f95a23c TL |
1628 | Directs matching traffic to the physical function (PF) of the current |
1629 | device. | |
1630 | ||
1631 | See `Item: PF`_. | |
11fdf7f2 TL |
1632 | |
1633 | - No configurable properties. | |
11fdf7f2 TL |
1634 | |
1635 | .. _table_rte_flow_action_pf: | |
1636 | ||
1637 | .. table:: PF | |
1638 | ||
1639 | +---------------+ | |
1640 | | Field | | |
1641 | +===============+ | |
1642 | | no properties | | |
1643 | +---------------+ | |
1644 | ||
1645 | Action: ``VF`` | |
1646 | ^^^^^^^^^^^^^^ | |
1647 | ||
9f95a23c | 1648 | Directs matching traffic to a given virtual function of the current device. |
11fdf7f2 TL |
1649 | |
1650 | Packets matched by a VF pattern item can be redirected to their original VF | |
1651 | ID instead of the specified one. This parameter may not be available and is | |
1652 | not guaranteed to work properly if the VF part is matched by a prior flow | |
1653 | rule or if packets are not addressed to a VF in the first place. | |
1654 | ||
9f95a23c | 1655 | See `Item: VF`_. |
11fdf7f2 TL |
1656 | |
1657 | .. _table_rte_flow_action_vf: | |
1658 | ||
1659 | .. table:: VF | |
1660 | ||
1661 | +--------------+--------------------------------+ | |
1662 | | Field | Value | | |
1663 | +==============+================================+ | |
1664 | | ``original`` | use original VF ID if possible | | |
1665 | +--------------+--------------------------------+ | |
9f95a23c | 1666 | | ``id`` | VF ID | |
11fdf7f2 TL |
1667 | +--------------+--------------------------------+ |
1668 | ||
9f95a23c TL |
1669 | Action: ``PHY_PORT`` |
1670 | ^^^^^^^^^^^^^^^^^^^^ | |
1671 | ||
1672 | Directs matching traffic to a given physical port index of the underlying | |
1673 | device. | |
1674 | ||
1675 | See `Item: PHY_PORT`_. | |
1676 | ||
1677 | .. _table_rte_flow_action_phy_port: | |
1678 | ||
1679 | .. table:: PHY_PORT | |
1680 | ||
1681 | +--------------+-------------------------------------+ | |
1682 | | Field | Value | | |
1683 | +==============+=====================================+ | |
1684 | | ``original`` | use original port index if possible | | |
1685 | +--------------+-------------------------------------+ | |
1686 | | ``index`` | physical port index | | |
1687 | +--------------+-------------------------------------+ | |
1688 | ||
1689 | Action: ``PORT_ID`` | |
1690 | ^^^^^^^^^^^^^^^^^^^ | |
1691 | Directs matching traffic to a given DPDK port ID. | |
1692 | ||
1693 | See `Item: PORT_ID`_. | |
1694 | ||
1695 | .. _table_rte_flow_action_port_id: | |
1696 | ||
1697 | .. table:: PORT_ID | |
1698 | ||
1699 | +--------------+---------------------------------------+ | |
1700 | | Field | Value | | |
1701 | +==============+=======================================+ | |
1702 | | ``original`` | use original DPDK port ID if possible | | |
1703 | +--------------+---------------------------------------+ | |
1704 | | ``id`` | DPDK port ID | | |
1705 | +--------------+---------------------------------------+ | |
1706 | ||
1707 | Action: ``METER`` | |
1708 | ^^^^^^^^^^^^^^^^^ | |
1709 | ||
1710 | Applies a stage of metering and policing. | |
1711 | ||
1712 | The metering and policing (MTR) object has to be first created using the | |
1713 | rte_mtr_create() API function. The ID of the MTR object is specified as | |
1714 | action parameter. More than one flow can use the same MTR object through | |
1715 | the meter action. The MTR object can be further updated or queried using | |
1716 | the rte_mtr* API. | |
1717 | ||
1718 | .. _table_rte_flow_action_meter: | |
1719 | ||
1720 | .. table:: METER | |
1721 | ||
1722 | +--------------+---------------+ | |
1723 | | Field | Value | | |
1724 | +==============+===============+ | |
1725 | | ``mtr_id`` | MTR object ID | | |
1726 | +--------------+---------------+ | |
1727 | ||
1728 | Action: ``SECURITY`` | |
1729 | ^^^^^^^^^^^^^^^^^^^^ | |
1730 | ||
1731 | Perform the security action on flows matched by the pattern items | |
1732 | according to the configuration of the security session. | |
1733 | ||
1734 | This action modifies the payload of matched flows. For INLINE_CRYPTO, the | |
1735 | security protocol headers and IV are fully provided by the application as | |
1736 | specified in the flow pattern. The payload of matching packets is | |
1737 | encrypted on egress, and decrypted and authenticated on ingress. | |
1738 | For INLINE_PROTOCOL, the security protocol is fully offloaded to HW, | |
1739 | providing full encapsulation and decapsulation of packets in security | |
1740 | protocols. The flow pattern specifies both the outer security header fields | |
1741 | and the inner packet fields. The security session specified in the action | |
1742 | must match the pattern parameters. | |
1743 | ||
1744 | The security session specified in the action must be created on the same | |
1745 | port as the flow action that is being specified. | |
1746 | ||
1747 | The ingress/egress flow attribute should match that specified in the | |
1748 | security session if the security session supports the definition of the | |
1749 | direction. | |
1750 | ||
1751 | Multiple flows can be configured to use the same security session. | |
1752 | ||
1753 | .. _table_rte_flow_action_security: | |
1754 | ||
1755 | .. table:: SECURITY | |
1756 | ||
1757 | +----------------------+--------------------------------------+ | |
1758 | | Field | Value | | |
1759 | +======================+======================================+ | |
1760 | | ``security_session`` | security session to apply | | |
1761 | +----------------------+--------------------------------------+ | |
1762 | ||
1763 | The following is an example of configuring IPsec inline using the | |
1764 | INLINE_CRYPTO security session: | |
1765 | ||
1766 | The encryption algorithm, keys and salt are part of the opaque | |
1767 | ``rte_security_session``. The SA is identified according to the IP and ESP | |
1768 | fields in the pattern items. | |
1769 | ||
1770 | .. _table_rte_flow_item_esp_inline_example: | |
1771 | ||
1772 | .. table:: IPsec inline crypto flow pattern items. | |
1773 | ||
1774 | +-------+----------+ | |
1775 | | Index | Item | | |
1776 | +=======+==========+ | |
1777 | | 0 | Ethernet | | |
1778 | +-------+----------+ | |
1779 | | 1 | IPv4 | | |
1780 | +-------+----------+ | |
1781 | | 2 | ESP | | |
1782 | +-------+----------+ | |
1783 | | 3 | END | | |
1784 | +-------+----------+ | |
1785 | ||
1786 | .. _table_rte_flow_action_esp_inline_example: | |
1787 | ||
1788 | .. table:: IPsec inline flow actions. | |
1789 | ||
1790 | +-------+----------+ | |
1791 | | Index | Action | | |
1792 | +=======+==========+ | |
1793 | | 0 | SECURITY | | |
1794 | +-------+----------+ | |
1795 | | 1 | END | | |
1796 | +-------+----------+ | |
1797 | ||
1798 | Action: ``OF_SET_MPLS_TTL`` | |
1799 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1800 | ||
1801 | Implements ``OFPAT_SET_MPLS_TTL`` ("MPLS TTL") as defined by the `OpenFlow | |
1802 | Switch Specification`_. | |
1803 | ||
1804 | .. _table_rte_flow_action_of_set_mpls_ttl: | |
1805 | ||
1806 | .. table:: OF_SET_MPLS_TTL | |
1807 | ||
1808 | +--------------+----------+ | |
1809 | | Field | Value | | |
1810 | +==============+==========+ | |
1811 | | ``mpls_ttl`` | MPLS TTL | | |
1812 | +--------------+----------+ | |
1813 | ||
1814 | Action: ``OF_DEC_MPLS_TTL`` | |
1815 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1816 | ||
1817 | Implements ``OFPAT_DEC_MPLS_TTL`` ("decrement MPLS TTL") as defined by the | |
1818 | `OpenFlow Switch Specification`_. | |
1819 | ||
1820 | .. _table_rte_flow_action_of_dec_mpls_ttl: | |
1821 | ||
1822 | .. table:: OF_DEC_MPLS_TTL | |
1823 | ||
1824 | +---------------+ | |
1825 | | Field | | |
1826 | +===============+ | |
1827 | | no properties | | |
1828 | +---------------+ | |
1829 | ||
1830 | Action: ``OF_SET_NW_TTL`` | |
1831 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1832 | ||
1833 | Implements ``OFPAT_SET_NW_TTL`` ("IP TTL") as defined by the `OpenFlow | |
1834 | Switch Specification`_. | |
1835 | ||
1836 | .. _table_rte_flow_action_of_set_nw_ttl: | |
1837 | ||
1838 | .. table:: OF_SET_NW_TTL | |
1839 | ||
1840 | +------------+--------+ | |
1841 | | Field | Value | | |
1842 | +============+========+ | |
1843 | | ``nw_ttl`` | IP TTL | | |
1844 | +------------+--------+ | |
1845 | ||
1846 | Action: ``OF_DEC_NW_TTL`` | |
1847 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1848 | ||
1849 | Implements ``OFPAT_DEC_NW_TTL`` ("decrement IP TTL") as defined by the | |
1850 | `OpenFlow Switch Specification`_. | |
1851 | ||
1852 | .. _table_rte_flow_action_of_dec_nw_ttl: | |
1853 | ||
1854 | .. table:: OF_DEC_NW_TTL | |
1855 | ||
1856 | +---------------+ | |
1857 | | Field | | |
1858 | +===============+ | |
1859 | | no properties | | |
1860 | +---------------+ | |
1861 | ||
1862 | Action: ``OF_COPY_TTL_OUT`` | |
1863 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1864 | ||
1865 | Implements ``OFPAT_COPY_TTL_OUT`` ("copy TTL "outwards" -- from | |
1866 | next-to-outermost to outermost") as defined by the `OpenFlow Switch | |
1867 | Specification`_. | |
1868 | ||
1869 | .. _table_rte_flow_action_of_copy_ttl_out: | |
1870 | ||
1871 | .. table:: OF_COPY_TTL_OUT | |
1872 | ||
1873 | +---------------+ | |
1874 | | Field | | |
1875 | +===============+ | |
1876 | | no properties | | |
1877 | +---------------+ | |
1878 | ||
1879 | Action: ``OF_COPY_TTL_IN`` | |
1880 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1881 | ||
1882 | Implements ``OFPAT_COPY_TTL_IN`` ("copy TTL "inwards" -- from outermost to | |
1883 | next-to-outermost") as defined by the `OpenFlow Switch Specification`_. | |
1884 | ||
1885 | .. _table_rte_flow_action_of_copy_ttl_in: | |
1886 | ||
1887 | .. table:: OF_COPY_TTL_IN | |
1888 | ||
1889 | +---------------+ | |
1890 | | Field | | |
1891 | +===============+ | |
1892 | | no properties | | |
1893 | +---------------+ | |
1894 | ||
1895 | Action: ``OF_POP_VLAN`` | |
1896 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
1897 | ||
1898 | Implements ``OFPAT_POP_VLAN`` ("pop the outer VLAN tag") as defined | |
1899 | by the `OpenFlow Switch Specification`_. | |
1900 | ||
1901 | .. _table_rte_flow_action_of_pop_vlan: | |
1902 | ||
1903 | .. table:: OF_POP_VLAN | |
1904 | ||
1905 | +---------------+ | |
1906 | | Field | | |
1907 | +===============+ | |
1908 | | no properties | | |
1909 | +---------------+ | |
1910 | ||
1911 | Action: ``OF_PUSH_VLAN`` | |
1912 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
1913 | ||
1914 | Implements ``OFPAT_PUSH_VLAN`` ("push a new VLAN tag") as defined by the | |
1915 | `OpenFlow Switch Specification`_. | |
1916 | ||
1917 | .. _table_rte_flow_action_of_push_vlan: | |
1918 | ||
1919 | .. table:: OF_PUSH_VLAN | |
1920 | ||
1921 | +---------------+-----------+ | |
1922 | | Field | Value | | |
1923 | +===============+===========+ | |
1924 | | ``ethertype`` | EtherType | | |
1925 | +---------------+-----------+ | |
1926 | ||
1927 | Action: ``OF_SET_VLAN_VID`` | |
1928 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1929 | ||
1930 | Implements ``OFPAT_SET_VLAN_VID`` ("set the 802.1q VLAN id") as defined by | |
1931 | the `OpenFlow Switch Specification`_. | |
1932 | ||
1933 | .. _table_rte_flow_action_of_set_vlan_vid: | |
1934 | ||
1935 | .. table:: OF_SET_VLAN_VID | |
1936 | ||
1937 | +--------------+---------+ | |
1938 | | Field | Value | | |
1939 | +==============+=========+ | |
1940 | | ``vlan_vid`` | VLAN id | | |
1941 | +--------------+---------+ | |
1942 | ||
1943 | Action: ``OF_SET_VLAN_PCP`` | |
1944 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1945 | ||
1946 | Implements ``OFPAT_SET_LAN_PCP`` ("set the 802.1q priority") as defined by | |
1947 | the `OpenFlow Switch Specification`_. | |
1948 | ||
1949 | .. _table_rte_flow_action_of_set_vlan_pcp: | |
1950 | ||
1951 | .. table:: OF_SET_VLAN_PCP | |
1952 | ||
1953 | +--------------+---------------+ | |
1954 | | Field | Value | | |
1955 | +==============+===============+ | |
1956 | | ``vlan_pcp`` | VLAN priority | | |
1957 | +--------------+---------------+ | |
1958 | ||
1959 | Action: ``OF_POP_MPLS`` | |
1960 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
1961 | ||
1962 | Implements ``OFPAT_POP_MPLS`` ("pop the outer MPLS tag") as defined by the | |
1963 | `OpenFlow Switch Specification`_. | |
1964 | ||
1965 | .. _table_rte_flow_action_of_pop_mpls: | |
1966 | ||
1967 | .. table:: OF_POP_MPLS | |
1968 | ||
1969 | +---------------+-----------+ | |
1970 | | Field | Value | | |
1971 | +===============+===========+ | |
1972 | | ``ethertype`` | EtherType | | |
1973 | +---------------+-----------+ | |
1974 | ||
1975 | Action: ``OF_PUSH_MPLS`` | |
1976 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
1977 | ||
1978 | Implements ``OFPAT_PUSH_MPLS`` ("push a new MPLS tag") as defined by the | |
1979 | `OpenFlow Switch Specification`_. | |
1980 | ||
1981 | .. _table_rte_flow_action_of_push_mpls: | |
1982 | ||
1983 | .. table:: OF_PUSH_MPLS | |
1984 | ||
1985 | +---------------+-----------+ | |
1986 | | Field | Value | | |
1987 | +===============+===========+ | |
1988 | | ``ethertype`` | EtherType | | |
1989 | +---------------+-----------+ | |
1990 | ||
1991 | Action: ``VXLAN_ENCAP`` | |
1992 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
1993 | ||
1994 | Performs a VXLAN encapsulation action by encapsulating the matched flow in the | |
1995 | VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow items | |
1996 | definition. | |
1997 | ||
1998 | This action modifies the payload of matched flows. The flow definition specified | |
1999 | in the ``rte_flow_action_tunnel_encap`` action structure must define a valid | |
2000 | VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible Local | |
2001 | Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks | |
2002 | over Layer 3 Networks). The pattern must be terminated with the | |
2003 | RTE_FLOW_ITEM_TYPE_END item type. | |
2004 | ||
2005 | .. _table_rte_flow_action_vxlan_encap: | |
2006 | ||
2007 | .. table:: VXLAN_ENCAP | |
2008 | ||
2009 | +----------------+-------------------------------------+ | |
2010 | | Field | Value | | |
2011 | +================+=====================================+ | |
2012 | | ``definition`` | Tunnel end-point overlay definition | | |
2013 | +----------------+-------------------------------------+ | |
2014 | ||
2015 | .. _table_rte_flow_action_vxlan_encap_example: | |
2016 | ||
2017 | .. table:: IPv4 VxLAN flow pattern example. | |
2018 | ||
2019 | +-------+----------+ | |
2020 | | Index | Item | | |
2021 | +=======+==========+ | |
2022 | | 0 | Ethernet | | |
2023 | +-------+----------+ | |
2024 | | 1 | IPv4 | | |
2025 | +-------+----------+ | |
2026 | | 2 | UDP | | |
2027 | +-------+----------+ | |
2028 | | 3 | VXLAN | | |
2029 | +-------+----------+ | |
2030 | | 4 | END | | |
2031 | +-------+----------+ | |
2032 | ||
2033 | Action: ``VXLAN_DECAP`` | |
2034 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2035 | ||
2036 | Performs a decapsulation action by stripping all headers of the VXLAN tunnel | |
2037 | network overlay from the matched flow. | |
2038 | ||
2039 | The flow items pattern defined for the flow rule with which a ``VXLAN_DECAP`` | |
2040 | action is specified, must define a valid VXLAN tunnel as per RFC7348. If the | |
2041 | flow pattern does not specify a valid VXLAN tunnel then a | |
2042 | RTE_FLOW_ERROR_TYPE_ACTION error should be returned. | |
2043 | ||
2044 | This action modifies the payload of matched flows. | |
2045 | ||
2046 | Action: ``NVGRE_ENCAP`` | |
2047 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2048 | ||
2049 | Performs a NVGRE encapsulation action by encapsulating the matched flow in the | |
2050 | NVGRE tunnel as defined in the``rte_flow_action_tunnel_encap`` flow item | |
2051 | definition. | |
2052 | ||
2053 | This action modifies the payload of matched flows. The flow definition specified | |
2054 | in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid | |
2055 | NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network | |
2056 | Virtualization Using Generic Routing Encapsulation). The pattern must be | |
2057 | terminated with the RTE_FLOW_ITEM_TYPE_END item type. | |
2058 | ||
2059 | .. _table_rte_flow_action_nvgre_encap: | |
2060 | ||
2061 | .. table:: NVGRE_ENCAP | |
2062 | ||
2063 | +----------------+-------------------------------------+ | |
2064 | | Field | Value | | |
2065 | +================+=====================================+ | |
2066 | | ``definition`` | NVGRE end-point overlay definition | | |
2067 | +----------------+-------------------------------------+ | |
2068 | ||
2069 | .. _table_rte_flow_action_nvgre_encap_example: | |
2070 | ||
2071 | .. table:: IPv4 NVGRE flow pattern example. | |
2072 | ||
2073 | +-------+----------+ | |
2074 | | Index | Item | | |
2075 | +=======+==========+ | |
2076 | | 0 | Ethernet | | |
2077 | +-------+----------+ | |
2078 | | 1 | IPv4 | | |
2079 | +-------+----------+ | |
2080 | | 2 | NVGRE | | |
2081 | +-------+----------+ | |
2082 | | 3 | END | | |
2083 | +-------+----------+ | |
2084 | ||
2085 | Action: ``NVGRE_DECAP`` | |
2086 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2087 | ||
2088 | Performs a decapsulation action by stripping all headers of the NVGRE tunnel | |
2089 | network overlay from the matched flow. | |
2090 | ||
2091 | The flow items pattern defined for the flow rule with which a ``NVGRE_DECAP`` | |
2092 | action is specified, must define a valid NVGRE tunnel as per RFC7637. If the | |
2093 | flow pattern does not specify a valid NVGRE tunnel then a | |
2094 | RTE_FLOW_ERROR_TYPE_ACTION error should be returned. | |
2095 | ||
2096 | This action modifies the payload of matched flows. | |
2097 | ||
2098 | Action: ``RAW_ENCAP`` | |
2099 | ^^^^^^^^^^^^^^^^^^^^^ | |
2100 | ||
2101 | Adds outer header whose template is provided in its data buffer, | |
2102 | as defined in the ``rte_flow_action_raw_encap`` definition. | |
2103 | ||
2104 | This action modifies the payload of matched flows. The data supplied must | |
2105 | be a valid header, either holding layer 2 data in case of adding layer 2 after | |
2106 | decap layer 3 tunnel (for example MPLSoGRE) or complete tunnel definition | |
2107 | starting from layer 2 and moving to the tunnel item itself. When applied to | |
2108 | the original packet the resulting packet must be a valid packet. | |
2109 | ||
2110 | .. _table_rte_flow_action_raw_encap: | |
2111 | ||
2112 | .. table:: RAW_ENCAP | |
2113 | ||
2114 | +----------------+----------------------------------------+ | |
2115 | | Field | Value | | |
2116 | +================+========================================+ | |
2117 | | ``data`` | Encapsulation data | | |
2118 | +----------------+----------------------------------------+ | |
2119 | | ``preserve`` | Bit-mask of data to preserve on output | | |
2120 | +----------------+----------------------------------------+ | |
2121 | | ``size`` | Size of data and preserve | | |
2122 | +----------------+----------------------------------------+ | |
2123 | ||
2124 | Action: ``RAW_DECAP`` | |
2125 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2126 | ||
2127 | Remove outer header whose template is provided in its data buffer, | |
2128 | as defined in the ``rte_flow_action_raw_decap`` | |
2129 | ||
2130 | This action modifies the payload of matched flows. The data supplied must | |
2131 | be a valid header, either holding layer 2 data in case of removing layer 2 | |
2132 | before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete | |
2133 | tunnel definition starting from layer 2 and moving to the tunnel item itself. | |
2134 | When applied to the original packet the resulting packet must be a | |
2135 | valid packet. | |
2136 | ||
2137 | .. _table_rte_flow_action_raw_decap: | |
2138 | ||
2139 | .. table:: RAW_DECAP | |
2140 | ||
2141 | +----------------+----------------------------------------+ | |
2142 | | Field | Value | | |
2143 | +================+========================================+ | |
2144 | | ``data`` | Decapsulation data | | |
2145 | +----------------+----------------------------------------+ | |
2146 | | ``size`` | Size of data | | |
2147 | +----------------+----------------------------------------+ | |
2148 | ||
2149 | Action: ``SET_IPV4_SRC`` | |
2150 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
2151 | ||
2152 | Set a new IPv4 source address in the outermost IPv4 header. | |
2153 | ||
2154 | It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV4 flow pattern item. | |
2155 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2156 | ||
2157 | .. _table_rte_flow_action_set_ipv4_src: | |
2158 | ||
2159 | .. table:: SET_IPV4_SRC | |
2160 | ||
2161 | +-----------------------------------------+ | |
2162 | | Field | Value | | |
2163 | +===============+=========================+ | |
2164 | | ``ipv4_addr`` | new IPv4 source address | | |
2165 | +---------------+-------------------------+ | |
2166 | ||
2167 | Action: ``SET_IPV4_DST`` | |
2168 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
2169 | ||
2170 | Set a new IPv4 destination address in the outermost IPv4 header. | |
2171 | ||
2172 | It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV4 flow pattern item. | |
2173 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2174 | ||
2175 | .. _table_rte_flow_action_set_ipv4_dst: | |
2176 | ||
2177 | .. table:: SET_IPV4_DST | |
2178 | ||
2179 | +---------------+------------------------------+ | |
2180 | | Field | Value | | |
2181 | +===============+==============================+ | |
2182 | | ``ipv4_addr`` | new IPv4 destination address | | |
2183 | +---------------+------------------------------+ | |
2184 | ||
2185 | Action: ``SET_IPV6_SRC`` | |
2186 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
2187 | ||
2188 | Set a new IPv6 source address in the outermost IPv6 header. | |
2189 | ||
2190 | It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV6 flow pattern item. | |
2191 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2192 | ||
2193 | .. _table_rte_flow_action_set_ipv6_src: | |
2194 | ||
2195 | .. table:: SET_IPV6_SRC | |
2196 | ||
2197 | +---------------+-------------------------+ | |
2198 | | Field | Value | | |
2199 | +===============+=========================+ | |
2200 | | ``ipv6_addr`` | new IPv6 source address | | |
2201 | +---------------+-------------------------+ | |
2202 | ||
2203 | Action: ``SET_IPV6_DST`` | |
2204 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
2205 | ||
2206 | Set a new IPv6 destination address in the outermost IPv6 header. | |
2207 | ||
2208 | It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV6 flow pattern item. | |
2209 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2210 | ||
2211 | .. _table_rte_flow_action_set_ipv6_dst: | |
2212 | ||
2213 | .. table:: SET_IPV6_DST | |
2214 | ||
2215 | +---------------+------------------------------+ | |
2216 | | Field | Value | | |
2217 | +===============+==============================+ | |
2218 | | ``ipv6_addr`` | new IPv6 destination address | | |
2219 | +---------------+------------------------------+ | |
2220 | ||
2221 | Action: ``SET_TP_SRC`` | |
2222 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
2223 | ||
2224 | Set a new source port number in the outermost TCP/UDP header. | |
2225 | ||
2226 | It must be used with a valid RTE_FLOW_ITEM_TYPE_TCP or RTE_FLOW_ITEM_TYPE_UDP | |
2227 | flow pattern item. Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2228 | ||
2229 | .. _table_rte_flow_action_set_tp_src: | |
2230 | ||
2231 | .. table:: SET_TP_SRC | |
2232 | ||
2233 | +----------+-------------------------+ | |
2234 | | Field | Value | | |
2235 | +==========+=========================+ | |
2236 | | ``port`` | new TCP/UDP source port | | |
2237 | +---------------+--------------------+ | |
2238 | ||
2239 | Action: ``SET_TP_DST`` | |
2240 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
2241 | ||
2242 | Set a new destination port number in the outermost TCP/UDP header. | |
2243 | ||
2244 | It must be used with a valid RTE_FLOW_ITEM_TYPE_TCP or RTE_FLOW_ITEM_TYPE_UDP | |
2245 | flow pattern item. Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2246 | ||
2247 | .. _table_rte_flow_action_set_tp_dst: | |
2248 | ||
2249 | .. table:: SET_TP_DST | |
2250 | ||
2251 | +----------+------------------------------+ | |
2252 | | Field | Value | | |
2253 | +==========+==============================+ | |
2254 | | ``port`` | new TCP/UDP destination port | | |
2255 | +---------------+-------------------------+ | |
2256 | ||
2257 | Action: ``MAC_SWAP`` | |
2258 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
2259 | ||
2260 | Swap the source and destination MAC addresses in the outermost Ethernet | |
2261 | header. | |
2262 | ||
2263 | It must be used with a valid RTE_FLOW_ITEM_TYPE_ETH flow pattern item. | |
2264 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2265 | ||
2266 | .. _table_rte_flow_action_mac_swap: | |
2267 | ||
2268 | .. table:: MAC_SWAP | |
2269 | ||
2270 | +---------------+ | |
2271 | | Field | | |
2272 | +===============+ | |
2273 | | no properties | | |
2274 | +---------------+ | |
2275 | ||
2276 | Action: ``DEC_TTL`` | |
2277 | ^^^^^^^^^^^^^^^^^^^ | |
2278 | ||
2279 | Decrease TTL value. | |
2280 | ||
2281 | If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6 | |
2282 | in pattern, Some PMDs will reject rule because behavior will be undefined. | |
2283 | ||
2284 | .. _table_rte_flow_action_dec_ttl: | |
2285 | ||
2286 | .. table:: DEC_TTL | |
2287 | ||
2288 | +---------------+ | |
2289 | | Field | | |
2290 | +===============+ | |
2291 | | no properties | | |
2292 | +---------------+ | |
2293 | ||
2294 | Action: ``SET_TTL`` | |
2295 | ^^^^^^^^^^^^^^^^^^^ | |
2296 | ||
2297 | Assigns a new TTL value. | |
2298 | ||
2299 | If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6 | |
2300 | in pattern, Some PMDs will reject rule because behavior will be undefined. | |
2301 | ||
2302 | .. _table_rte_flow_action_set_ttl: | |
2303 | ||
2304 | .. table:: SET_TTL | |
2305 | ||
2306 | +---------------+--------------------+ | |
2307 | | Field | Value | | |
2308 | +===============+====================+ | |
2309 | | ``ttl_value`` | new TTL value | | |
2310 | +---------------+--------------------+ | |
2311 | ||
2312 | Action: ``SET_MAC_SRC`` | |
2313 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2314 | ||
2315 | Set source MAC address. | |
2316 | ||
2317 | It must be used with a valid RTE_FLOW_ITEM_TYPE_ETH flow pattern item. | |
2318 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2319 | ||
2320 | .. _table_rte_flow_action_set_mac_src: | |
2321 | ||
2322 | .. table:: SET_MAC_SRC | |
2323 | ||
2324 | +--------------+---------------+ | |
2325 | | Field | Value | | |
2326 | +==============+===============+ | |
2327 | | ``mac_addr`` | MAC address | | |
2328 | +--------------+---------------+ | |
2329 | ||
2330 | Action: ``SET_MAC_DST`` | |
2331 | ^^^^^^^^^^^^^^^^^^^^^^^ | |
2332 | ||
2333 | Set destination MAC address. | |
2334 | ||
2335 | It must be used with a valid RTE_FLOW_ITEM_TYPE_ETH flow pattern item. | |
2336 | Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. | |
2337 | ||
2338 | .. _table_rte_flow_action_set_mac_dst: | |
2339 | ||
2340 | .. table:: SET_MAC_DST | |
2341 | ||
2342 | +--------------+---------------+ | |
2343 | | Field | Value | | |
2344 | +==============+===============+ | |
2345 | | ``mac_addr`` | MAC address | | |
2346 | +--------------+---------------+ | |
2347 | ||
11fdf7f2 TL |
2348 | Negative types |
2349 | ~~~~~~~~~~~~~~ | |
2350 | ||
2351 | All specified pattern items (``enum rte_flow_item_type``) and actions | |
2352 | (``enum rte_flow_action_type``) use positive identifiers. | |
2353 | ||
2354 | The negative space is reserved for dynamic types generated by PMDs during | |
2355 | run-time. PMDs may encounter them as a result but must not accept negative | |
2356 | identifiers they are not aware of. | |
2357 | ||
2358 | A method to generate them remains to be defined. | |
2359 | ||
2360 | Planned types | |
2361 | ~~~~~~~~~~~~~ | |
2362 | ||
2363 | Pattern item types will be added as new protocols are implemented. | |
2364 | ||
2365 | Variable headers support through dedicated pattern items, for example in | |
2366 | order to match specific IPv4 options and IPv6 extension headers would be | |
2367 | stacked after IPv4/IPv6 items. | |
2368 | ||
2369 | Other action types are planned but are not defined yet. These include the | |
2370 | ability to alter packet data in several ways, such as performing | |
2371 | encapsulation/decapsulation of tunnel headers. | |
2372 | ||
2373 | Rules management | |
2374 | ---------------- | |
2375 | ||
2376 | A rather simple API with few functions is provided to fully manage flow | |
2377 | rules. | |
2378 | ||
2379 | Each created flow rule is associated with an opaque, PMD-specific handle | |
2380 | pointer. The application is responsible for keeping it until the rule is | |
2381 | destroyed. | |
2382 | ||
2383 | Flows rules are represented by ``struct rte_flow`` objects. | |
2384 | ||
2385 | Validation | |
2386 | ~~~~~~~~~~ | |
2387 | ||
2388 | Given that expressing a definite set of device capabilities is not | |
2389 | practical, a dedicated function is provided to check if a flow rule is | |
2390 | supported and can be created. | |
2391 | ||
2392 | .. code-block:: c | |
2393 | ||
2394 | int | |
9f95a23c | 2395 | rte_flow_validate(uint16_t port_id, |
11fdf7f2 TL |
2396 | const struct rte_flow_attr *attr, |
2397 | const struct rte_flow_item pattern[], | |
2398 | const struct rte_flow_action actions[], | |
2399 | struct rte_flow_error *error); | |
2400 | ||
2401 | The flow rule is validated for correctness and whether it could be accepted | |
2402 | by the device given sufficient resources. The rule is checked against the | |
2403 | current device mode and queue configuration. The flow rule may also | |
2404 | optionally be validated against existing flow rules and device resources. | |
2405 | This function has no effect on the target device. | |
2406 | ||
2407 | The returned value is guaranteed to remain valid only as long as no | |
2408 | successful calls to ``rte_flow_create()`` or ``rte_flow_destroy()`` are made | |
2409 | in the meantime and no device parameter affecting flow rules in any way are | |
2410 | modified, due to possible collisions or resource limitations (although in | |
2411 | such cases ``EINVAL`` should not be returned). | |
2412 | ||
2413 | Arguments: | |
2414 | ||
2415 | - ``port_id``: port identifier of Ethernet device. | |
2416 | - ``attr``: flow rule attributes. | |
2417 | - ``pattern``: pattern specification (list terminated by the END pattern | |
2418 | item). | |
2419 | - ``actions``: associated actions (list terminated by the END action). | |
2420 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2421 | this structure in case of error only. | |
2422 | ||
2423 | Return values: | |
2424 | ||
2425 | - 0 if flow rule is valid and can be created. A negative errno value | |
2426 | otherwise (``rte_errno`` is also set), the following errors are defined. | |
2427 | - ``-ENOSYS``: underlying device does not support this functionality. | |
2428 | - ``-EINVAL``: unknown or invalid rule specification. | |
2429 | - ``-ENOTSUP``: valid but unsupported rule specification (e.g. partial | |
2430 | bit-masks are unsupported). | |
2431 | - ``EEXIST``: collision with an existing rule. Only returned if device | |
2432 | supports flow rule collision checking and there was a flow rule | |
2433 | collision. Not receiving this return code is no guarantee that creating | |
2434 | the rule will not fail due to a collision. | |
2435 | - ``ENOMEM``: not enough memory to execute the function, or if the device | |
2436 | supports resource validation, resource limitation on the device. | |
2437 | - ``-EBUSY``: action cannot be performed due to busy device resources, may | |
2438 | succeed if the affected queues or even the entire port are in a stopped | |
2439 | state (see ``rte_eth_dev_rx_queue_stop()`` and ``rte_eth_dev_stop()``). | |
2440 | ||
2441 | Creation | |
2442 | ~~~~~~~~ | |
2443 | ||
2444 | Creating a flow rule is similar to validating one, except the rule is | |
2445 | actually created and a handle returned. | |
2446 | ||
2447 | .. code-block:: c | |
2448 | ||
2449 | struct rte_flow * | |
9f95a23c | 2450 | rte_flow_create(uint16_t port_id, |
11fdf7f2 TL |
2451 | const struct rte_flow_attr *attr, |
2452 | const struct rte_flow_item pattern[], | |
2453 | const struct rte_flow_action *actions[], | |
2454 | struct rte_flow_error *error); | |
2455 | ||
2456 | Arguments: | |
2457 | ||
2458 | - ``port_id``: port identifier of Ethernet device. | |
2459 | - ``attr``: flow rule attributes. | |
2460 | - ``pattern``: pattern specification (list terminated by the END pattern | |
2461 | item). | |
2462 | - ``actions``: associated actions (list terminated by the END action). | |
2463 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2464 | this structure in case of error only. | |
2465 | ||
2466 | Return values: | |
2467 | ||
2468 | A valid handle in case of success, NULL otherwise and ``rte_errno`` is set | |
2469 | to the positive version of one of the error codes defined for | |
2470 | ``rte_flow_validate()``. | |
2471 | ||
2472 | Destruction | |
2473 | ~~~~~~~~~~~ | |
2474 | ||
2475 | Flow rules destruction is not automatic, and a queue or a port should not be | |
2476 | released if any are still attached to them. Applications must take care of | |
2477 | performing this step before releasing resources. | |
2478 | ||
2479 | .. code-block:: c | |
2480 | ||
2481 | int | |
9f95a23c | 2482 | rte_flow_destroy(uint16_t port_id, |
11fdf7f2 TL |
2483 | struct rte_flow *flow, |
2484 | struct rte_flow_error *error); | |
2485 | ||
2486 | ||
2487 | Failure to destroy a flow rule handle may occur when other flow rules depend | |
2488 | on it, and destroying it would result in an inconsistent state. | |
2489 | ||
2490 | This function is only guaranteed to succeed if handles are destroyed in | |
2491 | reverse order of their creation. | |
2492 | ||
2493 | Arguments: | |
2494 | ||
2495 | - ``port_id``: port identifier of Ethernet device. | |
2496 | - ``flow``: flow rule handle to destroy. | |
2497 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2498 | this structure in case of error only. | |
2499 | ||
2500 | Return values: | |
2501 | ||
2502 | - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. | |
2503 | ||
2504 | Flush | |
2505 | ~~~~~ | |
2506 | ||
2507 | Convenience function to destroy all flow rule handles associated with a | |
2508 | port. They are released as with successive calls to ``rte_flow_destroy()``. | |
2509 | ||
2510 | .. code-block:: c | |
2511 | ||
2512 | int | |
9f95a23c | 2513 | rte_flow_flush(uint16_t port_id, |
11fdf7f2 TL |
2514 | struct rte_flow_error *error); |
2515 | ||
2516 | In the unlikely event of failure, handles are still considered destroyed and | |
2517 | no longer valid but the port must be assumed to be in an inconsistent state. | |
2518 | ||
2519 | Arguments: | |
2520 | ||
2521 | - ``port_id``: port identifier of Ethernet device. | |
2522 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2523 | this structure in case of error only. | |
2524 | ||
2525 | Return values: | |
2526 | ||
2527 | - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. | |
2528 | ||
2529 | Query | |
2530 | ~~~~~ | |
2531 | ||
2532 | Query an existing flow rule. | |
2533 | ||
2534 | This function allows retrieving flow-specific data such as counters. Data | |
2535 | is gathered by special actions which must be present in the flow rule | |
2536 | definition. | |
2537 | ||
2538 | .. code-block:: c | |
2539 | ||
2540 | int | |
9f95a23c | 2541 | rte_flow_query(uint16_t port_id, |
11fdf7f2 | 2542 | struct rte_flow *flow, |
9f95a23c | 2543 | const struct rte_flow_action *action, |
11fdf7f2 TL |
2544 | void *data, |
2545 | struct rte_flow_error *error); | |
2546 | ||
2547 | Arguments: | |
2548 | ||
2549 | - ``port_id``: port identifier of Ethernet device. | |
2550 | - ``flow``: flow rule handle to query. | |
9f95a23c | 2551 | - ``action``: action to query, this must match prototype from flow rule. |
11fdf7f2 TL |
2552 | - ``data``: pointer to storage for the associated query data type. |
2553 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2554 | this structure in case of error only. | |
2555 | ||
2556 | Return values: | |
2557 | ||
2558 | - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. | |
2559 | ||
9f95a23c TL |
2560 | .. _flow_isolated_mode: |
2561 | ||
2562 | Flow isolated mode | |
2563 | ------------------ | |
2564 | ||
2565 | The general expectation for ingress traffic is that flow rules process it | |
2566 | first; the remaining unmatched or pass-through traffic usually ends up in a | |
2567 | queue (with or without RSS, locally or in some sub-device instance) | |
2568 | depending on the global configuration settings of a port. | |
2569 | ||
2570 | While fine from a compatibility standpoint, this approach makes drivers more | |
2571 | complex as they have to check for possible side effects outside of this API | |
2572 | when creating or destroying flow rules. It results in a more limited set of | |
2573 | available rule types due to the way device resources are assigned (e.g. no | |
2574 | support for the RSS action even on capable hardware). | |
2575 | ||
2576 | Given that nonspecific traffic can be handled by flow rules as well, | |
2577 | isolated mode is a means for applications to tell a driver that ingress on | |
2578 | the underlying port must be injected from the defined flow rules only; that | |
2579 | no default traffic is expected outside those rules. | |
2580 | ||
2581 | This has the following benefits: | |
2582 | ||
2583 | - Applications get finer-grained control over the kind of traffic they want | |
2584 | to receive (no traffic by default). | |
2585 | ||
2586 | - More importantly they control at what point nonspecific traffic is handled | |
2587 | relative to other flow rules, by adjusting priority levels. | |
2588 | ||
2589 | - Drivers can assign more hardware resources to flow rules and expand the | |
2590 | set of supported rule types. | |
2591 | ||
2592 | Because toggling isolated mode may cause profound changes to the ingress | |
2593 | processing path of a driver, it may not be possible to leave it once | |
2594 | entered. Likewise, existing flow rules or global configuration settings may | |
2595 | prevent a driver from entering isolated mode. | |
2596 | ||
2597 | Applications relying on this mode are therefore encouraged to toggle it as | |
2598 | soon as possible after device initialization, ideally before the first call | |
2599 | to ``rte_eth_dev_configure()`` to avoid possible failures due to conflicting | |
2600 | settings. | |
2601 | ||
2602 | Once effective, the following functionality has no effect on the underlying | |
2603 | port and may return errors such as ``ENOTSUP`` ("not supported"): | |
2604 | ||
2605 | - Toggling promiscuous mode. | |
2606 | - Toggling allmulticast mode. | |
2607 | - Configuring MAC addresses. | |
2608 | - Configuring multicast addresses. | |
2609 | - Configuring VLAN filters. | |
2610 | - Configuring Rx filters through the legacy API (e.g. FDIR). | |
2611 | - Configuring global RSS settings. | |
2612 | ||
2613 | .. code-block:: c | |
2614 | ||
2615 | int | |
2616 | rte_flow_isolate(uint16_t port_id, int set, struct rte_flow_error *error); | |
2617 | ||
2618 | Arguments: | |
2619 | ||
2620 | - ``port_id``: port identifier of Ethernet device. | |
2621 | - ``set``: nonzero to enter isolated mode, attempt to leave it otherwise. | |
2622 | - ``error``: perform verbose error reporting if not NULL. PMDs initialize | |
2623 | this structure in case of error only. | |
2624 | ||
2625 | Return values: | |
2626 | ||
2627 | - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. | |
2628 | ||
11fdf7f2 TL |
2629 | Verbose error reporting |
2630 | ----------------------- | |
2631 | ||
2632 | The defined *errno* values may not be accurate enough for users or | |
2633 | application developers who want to investigate issues related to flow rules | |
2634 | management. A dedicated error object is defined for this purpose: | |
2635 | ||
2636 | .. code-block:: c | |
2637 | ||
2638 | enum rte_flow_error_type { | |
2639 | RTE_FLOW_ERROR_TYPE_NONE, /**< No error. */ | |
2640 | RTE_FLOW_ERROR_TYPE_UNSPECIFIED, /**< Cause unspecified. */ | |
2641 | RTE_FLOW_ERROR_TYPE_HANDLE, /**< Flow rule (handle). */ | |
2642 | RTE_FLOW_ERROR_TYPE_ATTR_GROUP, /**< Group field. */ | |
2643 | RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY, /**< Priority field. */ | |
2644 | RTE_FLOW_ERROR_TYPE_ATTR_INGRESS, /**< Ingress field. */ | |
2645 | RTE_FLOW_ERROR_TYPE_ATTR_EGRESS, /**< Egress field. */ | |
2646 | RTE_FLOW_ERROR_TYPE_ATTR, /**< Attributes structure. */ | |
2647 | RTE_FLOW_ERROR_TYPE_ITEM_NUM, /**< Pattern length. */ | |
2648 | RTE_FLOW_ERROR_TYPE_ITEM, /**< Specific pattern item. */ | |
2649 | RTE_FLOW_ERROR_TYPE_ACTION_NUM, /**< Number of actions. */ | |
2650 | RTE_FLOW_ERROR_TYPE_ACTION, /**< Specific action. */ | |
2651 | }; | |
2652 | ||
2653 | struct rte_flow_error { | |
2654 | enum rte_flow_error_type type; /**< Cause field and error types. */ | |
2655 | const void *cause; /**< Object responsible for the error. */ | |
2656 | const char *message; /**< Human-readable error message. */ | |
2657 | }; | |
2658 | ||
2659 | Error type ``RTE_FLOW_ERROR_TYPE_NONE`` stands for no error, in which case | |
2660 | remaining fields can be ignored. Other error types describe the type of the | |
2661 | object pointed by ``cause``. | |
2662 | ||
2663 | If non-NULL, ``cause`` points to the object responsible for the error. For a | |
2664 | flow rule, this may be a pattern item or an individual action. | |
2665 | ||
2666 | If non-NULL, ``message`` provides a human-readable error message. | |
2667 | ||
2668 | This object is normally allocated by applications and set by PMDs in case of | |
2669 | error, the message points to a constant string which does not need to be | |
2670 | freed by the application, however its pointer can be considered valid only | |
2671 | as long as its associated DPDK port remains configured. Closing the | |
2672 | underlying device or unloading the PMD invalidates it. | |
2673 | ||
9f95a23c TL |
2674 | Helpers |
2675 | ------- | |
2676 | ||
2677 | Error initializer | |
2678 | ~~~~~~~~~~~~~~~~~ | |
2679 | ||
2680 | .. code-block:: c | |
2681 | ||
2682 | static inline int | |
2683 | rte_flow_error_set(struct rte_flow_error *error, | |
2684 | int code, | |
2685 | enum rte_flow_error_type type, | |
2686 | const void *cause, | |
2687 | const char *message); | |
2688 | ||
2689 | This function initializes ``error`` (if non-NULL) with the provided | |
2690 | parameters and sets ``rte_errno`` to ``code``. A negative error ``code`` is | |
2691 | then returned. | |
2692 | ||
2693 | Object conversion | |
2694 | ~~~~~~~~~~~~~~~~~ | |
2695 | ||
2696 | .. code-block:: c | |
2697 | ||
2698 | int | |
2699 | rte_flow_conv(enum rte_flow_conv_op op, | |
2700 | void *dst, | |
2701 | size_t size, | |
2702 | const void *src, | |
2703 | struct rte_flow_error *error); | |
2704 | ||
2705 | Convert ``src`` to ``dst`` according to operation ``op``. Possible | |
2706 | operations include: | |
2707 | ||
2708 | - Attributes, pattern item or action duplication. | |
2709 | - Duplication of an entire pattern or list of actions. | |
2710 | - Duplication of a complete flow rule description. | |
2711 | - Pattern item or action name retrieval. | |
2712 | ||
11fdf7f2 TL |
2713 | Caveats |
2714 | ------- | |
2715 | ||
2716 | - DPDK does not keep track of flow rules definitions or flow rule objects | |
2717 | automatically. Applications may keep track of the former and must keep | |
2718 | track of the latter. PMDs may also do it for internal needs, however this | |
2719 | must not be relied on by applications. | |
2720 | ||
2721 | - Flow rules are not maintained between successive port initializations. An | |
2722 | application exiting without releasing them and restarting must re-create | |
2723 | them from scratch. | |
2724 | ||
2725 | - API operations are synchronous and blocking (``EAGAIN`` cannot be | |
2726 | returned). | |
2727 | ||
9f95a23c | 2728 | - There is no provision for re-entrancy/multi-thread safety, although nothing |
11fdf7f2 TL |
2729 | should prevent different devices from being configured at the same |
2730 | time. PMDs may protect their control path functions accordingly. | |
2731 | ||
2732 | - Stopping the data path (TX/RX) should not be necessary when managing flow | |
2733 | rules. If this cannot be achieved naturally or with workarounds (such as | |
2734 | temporarily replacing the burst function pointers), an appropriate error | |
2735 | code must be returned (``EBUSY``). | |
2736 | ||
2737 | - PMDs, not applications, are responsible for maintaining flow rules | |
2738 | configuration when stopping and restarting a port or performing other | |
2739 | actions which may affect them. They can only be destroyed explicitly by | |
2740 | applications. | |
2741 | ||
2742 | For devices exposing multiple ports sharing global settings affected by flow | |
2743 | rules: | |
2744 | ||
2745 | - All ports under DPDK control must behave consistently, PMDs are | |
2746 | responsible for making sure that existing flow rules on a port are not | |
2747 | affected by other ports. | |
2748 | ||
2749 | - Ports not under DPDK control (unaffected or handled by other applications) | |
2750 | are user's responsibility. They may affect existing flow rules and cause | |
2751 | undefined behavior. PMDs aware of this may prevent flow rules creation | |
2752 | altogether in such cases. | |
2753 | ||
2754 | PMD interface | |
2755 | ------------- | |
2756 | ||
2757 | The PMD interface is defined in ``rte_flow_driver.h``. It is not subject to | |
2758 | API/ABI versioning constraints as it is not exposed to applications and may | |
2759 | evolve independently. | |
2760 | ||
2761 | It is currently implemented on top of the legacy filtering framework through | |
2762 | filter type *RTE_ETH_FILTER_GENERIC* that accepts the single operation | |
2763 | *RTE_ETH_FILTER_GET* to return PMD-specific *rte_flow* callbacks wrapped | |
2764 | inside ``struct rte_flow_ops``. | |
2765 | ||
2766 | This overhead is temporarily necessary in order to keep compatibility with | |
2767 | the legacy filtering framework, which should eventually disappear. | |
2768 | ||
2769 | - PMD callbacks implement exactly the interface described in `Rules | |
2770 | management`_, except for the port ID argument which has already been | |
2771 | converted to a pointer to the underlying ``struct rte_eth_dev``. | |
2772 | ||
2773 | - Public API functions do not process flow rules definitions at all before | |
2774 | calling PMD functions (no basic error checking, no validation | |
2775 | whatsoever). They only make sure these callbacks are non-NULL or return | |
2776 | the ``ENOSYS`` (function not supported) error. | |
2777 | ||
9f95a23c | 2778 | This interface additionally defines the following helper function: |
11fdf7f2 TL |
2779 | |
2780 | - ``rte_flow_ops_get()``: get generic flow operations structure from a | |
2781 | port. | |
2782 | ||
11fdf7f2 TL |
2783 | More will be added over time. |
2784 | ||
2785 | Device compatibility | |
2786 | -------------------- | |
2787 | ||
2788 | No known implementation supports all the described features. | |
2789 | ||
2790 | Unsupported features or combinations are not expected to be fully emulated | |
2791 | in software by PMDs for performance reasons. Partially supported features | |
2792 | may be completed in software as long as hardware performs most of the work | |
2793 | (such as queue redirection and packet recognition). | |
2794 | ||
2795 | However PMDs are expected to do their best to satisfy application requests | |
2796 | by working around hardware limitations as long as doing so does not affect | |
2797 | the behavior of existing flow rules. | |
2798 | ||
2799 | The following sections provide a few examples of such cases and describe how | |
2800 | PMDs should handle them, they are based on limitations built into the | |
2801 | previous APIs. | |
2802 | ||
2803 | Global bit-masks | |
2804 | ~~~~~~~~~~~~~~~~ | |
2805 | ||
2806 | Each flow rule comes with its own, per-layer bit-masks, while hardware may | |
2807 | support only a single, device-wide bit-mask for a given layer type, so that | |
2808 | two IPv4 rules cannot use different bit-masks. | |
2809 | ||
2810 | The expected behavior in this case is that PMDs automatically configure | |
2811 | global bit-masks according to the needs of the first flow rule created. | |
2812 | ||
2813 | Subsequent rules are allowed only if their bit-masks match those, the | |
2814 | ``EEXIST`` error code should be returned otherwise. | |
2815 | ||
2816 | Unsupported layer types | |
2817 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
2818 | ||
2819 | Many protocols can be simulated by crafting patterns with the `Item: RAW`_ | |
2820 | type. | |
2821 | ||
2822 | PMDs can rely on this capability to simulate support for protocols with | |
2823 | headers not directly recognized by hardware. | |
2824 | ||
2825 | ``ANY`` pattern item | |
2826 | ~~~~~~~~~~~~~~~~~~~~ | |
2827 | ||
2828 | This pattern item stands for anything, which can be difficult to translate | |
2829 | to something hardware would understand, particularly if followed by more | |
2830 | specific types. | |
2831 | ||
2832 | Consider the following pattern: | |
2833 | ||
2834 | .. _table_rte_flow_unsupported_any: | |
2835 | ||
2836 | .. table:: Pattern with ANY as L3 | |
2837 | ||
2838 | +-------+-----------------------+ | |
2839 | | Index | Item | | |
2840 | +=======+=======================+ | |
2841 | | 0 | ETHER | | |
2842 | +-------+-----+---------+-------+ | |
2843 | | 1 | ANY | ``num`` | ``1`` | | |
2844 | +-------+-----+---------+-------+ | |
2845 | | 2 | TCP | | |
2846 | +-------+-----------------------+ | |
2847 | | 3 | END | | |
2848 | +-------+-----------------------+ | |
2849 | ||
2850 | Knowing that TCP does not make sense with something other than IPv4 and IPv6 | |
2851 | as L3, such a pattern may be translated to two flow rules instead: | |
2852 | ||
2853 | .. _table_rte_flow_unsupported_any_ipv4: | |
2854 | ||
2855 | .. table:: ANY replaced with IPV4 | |
2856 | ||
2857 | +-------+--------------------+ | |
2858 | | Index | Item | | |
2859 | +=======+====================+ | |
2860 | | 0 | ETHER | | |
2861 | +-------+--------------------+ | |
2862 | | 1 | IPV4 (zeroed mask) | | |
2863 | +-------+--------------------+ | |
2864 | | 2 | TCP | | |
2865 | +-------+--------------------+ | |
2866 | | 3 | END | | |
2867 | +-------+--------------------+ | |
2868 | ||
2869 | | | |
2870 | ||
2871 | .. _table_rte_flow_unsupported_any_ipv6: | |
2872 | ||
2873 | .. table:: ANY replaced with IPV6 | |
2874 | ||
2875 | +-------+--------------------+ | |
2876 | | Index | Item | | |
2877 | +=======+====================+ | |
2878 | | 0 | ETHER | | |
2879 | +-------+--------------------+ | |
2880 | | 1 | IPV6 (zeroed mask) | | |
2881 | +-------+--------------------+ | |
2882 | | 2 | TCP | | |
2883 | +-------+--------------------+ | |
2884 | | 3 | END | | |
2885 | +-------+--------------------+ | |
2886 | ||
2887 | Note that as soon as a ANY rule covers several layers, this approach may | |
2888 | yield a large number of hidden flow rules. It is thus suggested to only | |
2889 | support the most common scenarios (anything as L2 and/or L3). | |
2890 | ||
2891 | Unsupported actions | |
2892 | ~~~~~~~~~~~~~~~~~~~ | |
2893 | ||
2894 | - When combined with `Action: QUEUE`_, packet counting (`Action: COUNT`_) | |
2895 | and tagging (`Action: MARK`_ or `Action: FLAG`_) may be implemented in | |
2896 | software as long as the target queue is used by a single rule. | |
2897 | ||
11fdf7f2 TL |
2898 | - When a single target queue is provided, `Action: RSS`_ can also be |
2899 | implemented through `Action: QUEUE`_. | |
2900 | ||
2901 | Flow rules priority | |
2902 | ~~~~~~~~~~~~~~~~~~~ | |
2903 | ||
2904 | While it would naturally make sense, flow rules cannot be assumed to be | |
2905 | processed by hardware in the same order as their creation for several | |
2906 | reasons: | |
2907 | ||
2908 | - They may be managed internally as a tree or a hash table instead of a | |
2909 | list. | |
2910 | - Removing a flow rule before adding another one can either put the new rule | |
2911 | at the end of the list or reuse a freed entry. | |
2912 | - Duplication may occur when packets are matched by several rules. | |
2913 | ||
2914 | For overlapping rules (particularly in order to use `Action: PASSTHRU`_) | |
2915 | predictable behavior is only guaranteed by using different priority levels. | |
2916 | ||
2917 | Priority levels are not necessarily implemented in hardware, or may be | |
2918 | severely limited (e.g. a single priority bit). | |
2919 | ||
2920 | For these reasons, priority levels may be implemented purely in software by | |
2921 | PMDs. | |
2922 | ||
2923 | - For devices expecting flow rules to be added in the correct order, PMDs | |
2924 | may destroy and re-create existing rules after adding a new one with | |
2925 | a higher priority. | |
2926 | ||
2927 | - A configurable number of dummy or empty rules can be created at | |
2928 | initialization time to save high priority slots for later. | |
2929 | ||
2930 | - In order to save priority levels, PMDs may evaluate whether rules are | |
2931 | likely to collide and adjust their priority accordingly. | |
2932 | ||
2933 | Future evolutions | |
2934 | ----------------- | |
2935 | ||
2936 | - A device profile selection function which could be used to force a | |
2937 | permanent profile instead of relying on its automatic configuration based | |
2938 | on existing flow rules. | |
2939 | ||
2940 | - A method to optimize *rte_flow* rules with specific pattern items and | |
2941 | action types generated on the fly by PMDs. DPDK should assign negative | |
2942 | numbers to these in order to not collide with the existing types. See | |
2943 | `Negative types`_. | |
2944 | ||
2945 | - Adding specific egress pattern items and actions as described in | |
2946 | `Attribute: Traffic direction`_. | |
2947 | ||
2948 | - Optional software fallback when PMDs are unable to handle requested flow | |
2949 | rules so applications do not have to implement their own. | |
2950 | ||
9f95a23c | 2951 | .. _OpenFlow Switch Specification: https://www.opennetworking.org/software-defined-standards/specifications/ |