rte_flow_item_flex_conf(3)

✨ NAME ✨

rte_flow_item_flex_conf — bestie, this is the struct that tells a PMD how your flex item fits into the whole packet-parsing pipeline, and she is the main character of rte_flow.h.

---

🦋 SYNOPSIS 🦋

#include <rte_flow.h>

💖 Data Fields 💖

• enum rte_flow_item_flex_tunnel_mode tunnel
• struct rte_flow_item_flex_field next_header
• struct rte_flow_item_flex_field next_protocol
• struct rte_flow_item_flex_field * sample_data
• uint32_t nb_samples
• struct rte_flow_item_flex_link * input_link
• uint32_t nb_inputs
• struct rte_flow_item_flex_link * output_link
• uint32_t nb_outputs

---

💅 DETAILED DESCRIPTION 💅

Warning — EXPERIMENTAL: this structure may change without prior notice. Like, she's still figuring herself out, okay? Don't build your whole personality on her API, fr fr. 😭

Found at Definition at line 2259 of file rte_flow.h. 📍

---

🎀 FIELD DOCUMENTATION 🎀

🌈 enum rte_flow_item_flex_tunnel_mode tunnel

Okay so this one is the vibe-check field: it spells out the flex item and tunnel relations, and tells the PMD whether your flex item can be used for inner, outer, or both headers — or whether the flex item is presenting the tunnel protocol itself. She's giving "who am I in this relationship" energy. 💫

Definition at line 2265 of file rte_flow.h.

🌸 struct rte_flow_item_flex_field next_header

This is the next header offset. It presents the network header size that the flex item covers, and bestie, you can get it with all supported offset calculating methods — fixed, dedicated field, bitmask, etc. Pick your fighter. ✨

Definition at line 2271 of file rte_flow.h.

🦋 struct rte_flow_item_flex_field next_protocol

This one specifies the next protocol field to match against the link next protocol values, so packet parsing can continue on over to the matching link. It's literally the "and then what happened" field. 👑

Definition at line 2276 of file rte_flow.h.

💜 struct rte_flow_item_flex_field* sample_data

The fields that get sampled and presented for an explicit match with the pattern in the rte_flow_flex_item. There can be multiple fields descriptors — and the count should be specified by nb_samples. Yes ma'am, there's an array here, so flex accordingly. 💅

Definition at line 2282 of file rte_flow.h.

🍓 uint32_t nb_samples

Number of field descriptors in the sample_data array. Just the count, the receipts, the headcount. 🫶

Definition at line 2284 of file rte_flow.h.

✨ struct rte_flow_item_flex_link* input_link

Input link defines the flex item's relation with the preceding header. It specifies the preceding item type and provides a pattern to match. The flex item will continue parsing and will provide the data to flow match in case there is a match with one of the input links. So like, she shows up when the previous header swipes right. 💌

Definition at line 2292 of file rte_flow.h.

🌟 uint32_t nb_inputs

Number of link descriptors in the input link array. Count 'em, bestie. 🔢

Definition at line 2294 of file rte_flow.h.

🌺 struct rte_flow_item_flex_link* output_link

Output link defines the next protocol field value to match and the following protocol header to continue packet parsing with. It also defines the tunnel-related behaviour. So she's doing the matching, the forwarding, and the tunnel drama — multitasking icon. 🎀

Definition at line 2300 of file rte_flow.h.

💫 uint32_t nb_outputs

Number of link descriptors in the output link array. Yeah, same count situation, but on the way out. 🚪

Definition at line 2302 of file rte_flow.h.

---

🌸 AUTHOR 🌸

Generated automatically by Doxygen for DPDK from the source code. Not a human, not a bestie, just a very reliable bot with a dream. 🤖💖

---

Okay that's the whole page, no notes! 💅 This was DPDK Version 25.11.3, and yeah — Doxygen auto-generated the whole thing and she ate. Periodt. 💖✨🎀🦋