rte_event(3)

🦋 NAME 🦋

okay so bestie, today we're learning about rte_event — she's a Library Functions Manual girlie, and literally the whole page is about one iconic little struct 💅

---

✨ SYNOPSIS ✨

#include <rte_eventdev.h>

---

💖 Detailed Description 💖

So rte_event is the generic struct — the main character — that holds all the event attributes you need for a dequeue and enqueue operation. That's it, that's her job 🫶

Definition at line 1676 of file rte_eventdev.h.

---

🎀 Field Documentation 🎀

🌸 uint32_t flow_id 🌸

This is the target flow identifier for the enqueue and dequeue operation, periodt.

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 only ever get scheduled to one port at a time. no cap, very orderly 💅

This field is 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 😭

Definition at line 1682 of file rte_eventdev.h.

🌈 uint32_t sub_event_type 🌈

Sub-event types, based on the event source, bestie.

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 to classify the event source — it's a RTE_EVENT_TYPE_* situation.

This field is preserved between enqueue and dequeue 🎀

Definition at line 1701 of file rte_eventdev.h.

💀 uint8_t op 💀

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

Okay so heads up 🙈 this field is not preserved across an instance, and it's implementation dependent on dequeue.

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, iykyk.

You should set it to zero when initializing event structures ✍️

But when you're forwarding or releasing existing events that you dequeued from the scheduler, this field can just be ignored. she's just vibing 💅

Definition at line 1716 of file rte_eventdev.h.

🔥 uint8_t sched_type 🔥

The scheduler synchronization type (RTE_SCHED_TYPE_*) associated with flow_id on a given event queue, for the enqueue and dequeue operation.

This field is what determines 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, bestie 🚨

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 👑

The 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().

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]

This one's 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.) 😭 math is mathing

It's ignored when the device does not support the RTE_EVENT_DEV_CAP_EVENT_QOS capability, and it's implementation dependent whether this field is preserved between enqueue and dequeue 🙈

Definition at line 1749 of file rte_eventdev.h.

💜 uint8_t impl_opaque 💜

An 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 it must be returned unmodified on enqueue when the 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.

Definition at line 1773 of file rte_eventdev.h.

🌟 uint64_t u64 🌟

Opaque 64-bit value 💅

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 — for when 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, bestie ⭐

Definition at line 1797 of file rte_eventdev.h.

---

💅 Author 💅

Generated automatically by Doxygen for DPDK from the source code. not a human wrote this one, the robots ate 🫶

---

and that's the whole page!! 💖 this was Version 26.03.0 of DPDK, dated rte_event(3), and yeah — the docs literally auto-generated themselves, we love a self-sufficient queen 👑✨ see u next time bestie!! 🎀