rte_flow_item(3)

💖 rte_flow_item 💖

okay bestie, so this is a page from the Library Functions Manual — it's rte_flow_item(3), and it's literally the whole vibe of how a matching pattern item gets defined in DPDK. it's giving "the blueprint of pattern matching" and honestly? iconic. let's get into it 🦋

---

✨ SYNOPSIS ✨

#include <rte_flow.h>

🎀 Data Fields

• enum rte_flow_item_type type
• const void * spec
• const void * last
• const void * mask

---

🌸 DETAILED DESCRIPTION 🌸

Matching pattern item definition. periodt.

so a pattern gets built by stacking items, and you start from the lowest protocol layer you wanna match, then go up from there. no cap.

but bestie, hear me — this stacking restriction does not apply to meta items. those can be dropped anywhere in the stack without changing the meaning of the resulting pattern. main character energy fr fr. 👑

and how do patterns know when to stop? Patterns are terminated by END items. that's the closer, that's the mic drop. 💅

the spec field, explained with love

spec should be a valid pointer to a structure of the related item type. it may remain unspecified (NULL) in many cases, and that's totally fine — it just means you're requesting broad (nonspecific) matching. lowkey chill of you.

⚠️ but listen: in those cases, last and mask must also be set to NULL. all three or nothing, bestie. no half-commitments. 😭

the last field, aka range queen

optionally, last can point to a structure of the same type to define an inclusive range. it's mostly supported by integer and address fields — for anything else it may cause errors, so don't be reckless 🫶

and the fields that don't support ranges? they must be set to 0 or to the same value as the corresponding fields in spec. match the energy or set it to zero, no in-between. ✨

the mask field, the bit-manipulator of the group

by default, only the fields defined to nonzero values in the default masks (see the rte_flow_item_{name}_mask constants) are considered relevant. that's the default, that's just how she operates.

you can override this by providing a mask structure of the same type with the applicable bits set to one. 🌈 you can also use it to partially filter out specific fields — for example, as an alternate mean to match ranges of IP addresses. sneaky and valid, we love her.

mask is a simple bit-mask applied before interpreting the contents of spec and last, which may yield unexpected results if not used carefully. this is your reminder that bit math does not care about your feelings. 💀

for example, if for an IPv4 address field:

• spec provides 10.1.2.3
• last provides 10.3.4.5
• mask provides 255.255.0.0

then the effective range becomes 10.1.0.0 to 10.3.255.255. see how the mask rewrote the whole story? ate. 💅

Definition at line 2127 of file rte_flow.h.

---

👑 FIELD DOCUMENTATION 👑

enum rte_flow_item_type type

Item type. that's it, that's the label on the box, bestie.

Definition at line 2128 of file rte_flow.h.

const void* spec

Pointer to item specification structure. this is the "what are we even looking for" pointer. 🔍

Definition at line 2129 of file rte_flow.h.

const void* last

Defines an inclusive range (spec to last). from here to here, inclusive, no takebacks. 💖

Definition at line 2130 of file rte_flow.h.

const void* mask

Bit-mask applied to spec and last. the vibe filter, essentially. 🎀

Definition at line 2131 of file rte_flow.h.

---

🧚 AUTHOR 🧚

Generated automatically by Doxygen for DPDK from the source code. (yes she was born from a doc generator and she's still slaying, cry about it 😭)

---

okay so that was the whole page, mwah 🫶 and just so you know who's responsible for this masterpiece — it's DPDK, Version 25.11.3, and this whole lil doc came straight from the source code via Doxygen. byeeee, go match some patterns 💖✨🌸