rte_event(3)

💖 rte_event 💖

okay bestie, today we're getting into rte_event — yes, that's the whole name, that's the vibe, we're keeping it. This one lives in the rte_eventdev.h header and it's literally the generic event struct that holds all your event attributes for dequeue and enqueue operations. main character struct energy, no cap. 🎀

It's defined at line 1676 of rte_eventdev.h, if you're the kind of girl who needs receipts (iconic of you).

---

✨ SYNOPSIS ✨

#include <rte_eventdev.h>

---

🌸 DETAILED DESCRIPTION 🌸

So like, the generic rte_event structure is the thing that holds the event attributes for your dequeue and enqueue operation. That's it. That's the whole job. Simple, effective, slaying.

Definition at line 1676 of file rte_eventdev.h. 📍

---

🦋 FIELD DOCUMENTATION 🦋

Every field, one by one, because we do NOT skip parts in this house 💅

uint32_t flow_id

Target flow identifier for the enqueue and dequeue operation. 🎯

For RTE_SCHED_TYPE_ATOMIC, this field is what identifies a flow for atomicity within a queue & priority level — so events from each individual flow get scheduled to only ONE port at a time. one port, one flow, no sharing, periodt.

This field gets preserved between enqueue and dequeue when a device reports the RTE_EVENT_DEV_CAP_CARRY_FLOW_ID capability. Otherwise? The value is implementation dependent on dequeue, aka it's giving "your mileage may vary" 🙈

Definition at line 1682 of file rte_eventdev.h. 📍

uint32_t sub_event_type

Sub-event types based on the event source.

This field IS preserved between enqueue and dequeue. 💖

See also:

• RTE_EVENT_TYPE_CPU

Definition at line 1694 of file rte_eventdev.h. 📍

uint32_t event_type

Event type used to classify the event source. (RTE_EVENT_TYPE_*)

This field is preserved between enqueue and dequeue. periodt.

Definition at line 1701 of file rte_eventdev.h. 📍

uint8_t op

The type of event enqueue operation — new/forward/etc. 🚀

Heads up bestie: this field is NOT preserved across an instance, and it's implementation dependent on dequeue. so don't be relying on it, she's fickle.

See also:

• RTE_EVENT_OP_NEW
• RTE_EVENT_OP_FORWARD
• RTE_EVENT_OP_RELEASE

Definition at line 1706 of file rte_eventdev.h. 📍

uint8_t rsvd

Reserved for future use. ✨ (manifesting what's to come)

Should be set to zero when you're initializing event structures.

BUT — when you're forwarding or releasing existing events that you dequeued from the scheduler, this field can be ignored. so like, chill.

Definition at line 1716 of file rte_eventdev.h. 📍

uint8_t sched_type

Scheduler synchronization type (RTE_SCHED_TYPE_*) associated with flow id on a given event queue for the enqueue and dequeue operation.

This field is used to determine the scheduling type for events sent to queues where RTE_EVENT_QUEUE_CFG_ALL_TYPES is configured. For queues where only a single scheduling type is available, this field must be set to match the configured scheduling type. no wiggle room, she said what she said.

This field is preserved between enqueue and dequeue. 💅

See also:

• RTE_SCHED_TYPE_ORDERED
• RTE_SCHED_TYPE_ATOMIC
• RTE_SCHED_TYPE_PARALLEL

Definition at line 1724 of file rte_eventdev.h. 📍

uint8_t queue_id

Targeted event queue identifier for the enqueue or dequeue operation. The value must be less than nb_event_queues, which was previously supplied to rte_event_dev_configure(). so like, don't just make numbers up, bestie 😭

This field is preserved between enqueue on dequeue.

Definition at line 1741 of file rte_eventdev.h. 📍

uint8_t priority

Event priority relative to other events in the event queue. The requested priority should be in the range of [RTE_EVENT_DEV_PRIORITY_HIGHEST, RTE_EVENT_DEV_PRIORITY_LOWEST].

The implementation shall normalize the requested priority to a supported priority value. [For devices where the supported priority range is a power-of-2, the normalization will be done via bit-shifting, so only the highest log2(num_priorities) bits will be used by the event device] 🧮

Valid when the device has the RTE_EVENT_DEV_CAP_EVENT_QOS capability, and this field is preserved between enqueue and dequeue — though with possible loss of precision due to normalization and subsequent de-normalization. (For example, if a device only supports 8 priority levels, only the high 3 bits of this field will be used by that device, and hence only the value of those 3 bits are guaranteed to be preserved between enqueue and dequeue.) ✨ the precision loss is real and she's not sorry

Ignored when the device does not support RTE_EVENT_DEV_CAP_EVENT_QOS capability, and it is implementation dependent if this field is preserved between enqueue and dequeue.

Definition at line 1749 of file rte_eventdev.h. 📍

uint8_t impl_opaque

Opaque field for event device use. 👀

An event driver implementation may use this field to hold an implementation specific value to share between dequeue and enqueue operation.

The application must not modify this field. 🚫 Its value is implementation dependent on dequeue, and must be returned unmodified on enqueue when op type is RTE_EVENT_OP_FORWARD or RTE_EVENT_OP_RELEASE. This field is ignored on events with op type RTE_EVENT_OP_NEW. so hands off, she's not yours

Definition at line 1773 of file rte_eventdev.h. 📍

uint64_t u64

Opaque 64-bit value. 🔮 mysterious, iconic, no further questions

Definition at line 1791 of file rte_eventdev.h. 📍

void* event_ptr

Opaque event pointer. 🫶

Definition at line 1793 of file rte_eventdev.h. 📍

struct rte_mbuf* mbuf

mbuf pointer if the dequeued event is associated with an mbuf. 📦

Definition at line 1795 of file rte_eventdev.h. 📍

struct rte_event_vector* vec

Event vector pointer. 🌈

Definition at line 1797 of file rte_eventdev.h. 📍

---

👑 AUTHOR 👑

Generated automatically by Doxygen for DPDK from the source code. (yes, a robot wrote this, and honestly? it ate. slay, Doxygen. 🤖✨)

---

okay that's the whole page bestie, you're officially an rte_event expert, go forth and enqueue responsibly 💖🎀✨

luv u, bye — this was DPDK Version 25.11.3, rte_event(3) 🦋