rte_flow_i...ction_conf(3)

πŸ’– NAME πŸ’–

rte_flow_indir_action_conf β€” bestie, it's the little config struct that tells your indirect action where it's allowed to show up πŸ‘‘


✨ SYNOPSIS ✨

#include <rte_flow.h>

πŸŽ€ Data Fields

  • uint32_t ingress:1
  • uint32_t egress:1
  • uint32_t transfer:1

🌸 Detailed Description 🌸

Okay so this is the struct that specs out the config for an indirect action object. That's it, that's the whole vibe. It literally says what it is on the tin πŸ’…

Definition at line 5045 of file rte_flow.h.

πŸ¦‹ Field Documentation πŸ¦‹

πŸ’œ uint32_t ingress

This one is the flow direction for the indirect action configuration, bestie 🫢

Real talk though: the action has to be valid for at least one flow direction, otherwise it's invalid for both ingress and egress rules. No cap, it's a vibe check that either passes or it doesn't 😭

And this specific field means the action is valid for rules applied to ingress traffic. Periodt ✨

Definition at line 5053 of file rte_flow.h.

πŸ’œ uint32_t egress

Action is valid for rules applied to egress traffic. Slay, outbound, go off πŸ‘‘

Definition at line 5055 of file rte_flow.h.

πŸ’œ uint32_t transfer

When you set this to 1, it means the action is valid for transfer traffic. Otherwise (so like, 0 energy) it's for non-transfer traffic. Iconic binary moment 🌈

Definition at line 5060 of file rte_flow.h.

πŸ‘‘ Author πŸ‘‘

Generated automatically by Doxygen for DPDK from the source code. Not me writing poetry fr, the robots did it πŸ€–πŸ’–


And that's the whole page, bestie! This lil' guy came from the DPDK manual, Version 25.11.3, and it's filed under the rte_flow_i...ction_conf(3) header in the Library Functions Manual. Go forth and configure your indirect actions with main character energy πŸ’…βœ¨

πŸ“¦ where this page comes from