rte_flow_attr(3)

📦
version 25.11.3 · 9 versions
, in ubuntu resolute, ubuntu stonking

💖 rte_flow_attr(3) 💖

okay bestie, sit down, hydrate, and let's talk about rte_flow_attr — it's a thing from the DPDK library functions manual and it's literally the ✨vibe sheet✨ for your flow rules. this is the page for the struct itself, no cap.

🌸 NAME 🌸

rte_flow_attr — the struct that holds the attributes of a flow rule, and honestly? she's kind of the main character.

🎀 SYNOPSIS 🎀

#include <rte_flow.h>

✨ Data Fields ✨

  • uint32_t group
  • uint32_t priority
  • uint32_t ingress:1
  • uint32_t egress:1
  • uint32_t transfer:1
  • uint32_t reserved:29

🦋 Detailed Description 🦋

so. Flow rule attributes. that's the whole point of this struct, periodt.

Priorities are set on a per rule basis, and that's within groups. important nuance, don't skip it.

Lower values denote higher priority 🫶 and the highest priority a flow rule can have is 0. so if a flow matches for than one rule, the rule with the lowest priority value will always be matched. the math is mathing.

Although it's optional, applications are encouraged to group similar rules as much as possible — that way you fully take advantage of hardware capabilities (think optimized matching, slay) and you also work around limitations (for example, a single pattern type possibly allowed in a given group). also, apps should be aware that groups are not linked by default, and they must be explicitly linked by the application using the JUMP action. like, you have to actually do that. no autopilot, bestie.

Priority levels are arbitrary and it's fully up to the application — they don't need to be contiguous and they don't need to start from 0. BUT. the maximum number varies between devices and may be affected by existing flow rules. so watch out.

💀 If a packet is matched by several rules of a given group for a given priority level, the outcome is undefined. It can take any path, may be duplicated, or even cause unrecoverable errors. not a drill. not cute. be careful.

Also note that support for more than a single group and priority level is not guaranteed. 🙈

At vNIC / ethdev level, flow rules can apply to inbound and / or outbound traffic (ingress / egress), with respect to the vNIC / ethdev in question. At embedded switch level, flow rules apply to all traffic seen by it unless fitting meta items are used to set concrete traffic source(s).

Several pattern items and actions are valid and can be used in both directions. Those valid for only one direction are described as such.

At least one direction must be specified. like, mandatory mandatory.

Specifying both directions at once for a given rule is not recommended, but it may be valid in a few cases. so... rare permission slip.

Definition at line 89 of file rte_flow.h.

🔥 Field Documentation 🔥

💜 uint32_t group

A group is a superset of multiple rules. the default group is 0 and it's processed for all packets. Rules in other groups are processed only if the group is chained by a jump action from a previously matched rule. so basically, the group hierarchy is made by the flow rules themselves, and group 0 is the hierarchy root, the queen bee 👑. also note there is no automatic dead loop protection — you're on your own for that one.

See also

rte_flow_action_jump

Definition at line 100 of file rte_flow.h.

💜 uint32_t priority

Rule priority level within group. that's it, that's the whole field.

Definition at line 101 of file rte_flow.h.

💜 uint32_t ingress

The rule in question applies to ingress traffic (non-"transfer"). coming in 🚪✨

Definition at line 105 of file rte_flow.h.

💜 uint32_t egress

The rule in question applies to egress traffic (non-"transfer"). going out 🚪💨

Definition at line 109 of file rte_flow.h.

💜 uint32_t transfer

Instead of simply matching the properties of traffic as it would appear on a given DPDK port ID, enabling this attribute transfers a flow rule to the lowest possible level of any device endpoints found in the pattern. it's giving glow-down-to-the-metal, honestly.

When supported, this effectively enables an application to re-route traffic not necessarily intended for it (e.g. coming from or addressed to different physical ports, VFs or applications) at the device level. iconic.

The application should match traffic originating from precise locations. See items PORT_REPRESENTOR and REPRESENTED_PORT. be specific, bestie, specificity is self care.

Managing "transfer" flows requires that the user communicate them through a suitable port.

See also

rte_flow_pick_transfer_proxy().

Definition at line 127 of file rte_flow.h.

💜 uint32_t reserved

Reserved, must be zero. no touching, no filling, no creativity. zero. 🚫

Definition at line 128 of file rte_flow.h.

⭐ Author ⭐

Generated automatically by Doxygen for DPDK from the source code. (not a human, not a girlboss, just Doxygen doing its thing 💅)

and that's the page, bestie!! this was DPDK Version 25.11.3, rte_flow_attr(3), and if you made it to the end you deserve a little treat 🍓 — go forth and configure your flow rules responsibly, mwah 💖✨🦋

📦 where this page comes from