rte_eventdev.h(3)
🎀 rte_eventdev.h 🎀
okay bestie, welcome to the rte_eventdev.h(3) glow-up — this is the DPDK manual page, section 3 (that's the "library functions" section, iykyk), and we're gonna get you so comfy with it 💅✨
✨ NAME ✨
rte_eventdev.h 🦋
that's it. that's the name. short, iconic, main character energy — no cap 💖
✨ SYNOPSIS ✨
okay so first things first, you gotta pull in the headers. all of them. like a full fit check before we go anywhere 💅
#include <rte_bitops.h>
#include <rte_common.h>
#include <rte_compat.h>
#include <rte_errno.h>
#include <rte_mbuf_pool_ops.h>
#include <rte_mempool.h>
#include 'rte_eventdev_trace_fp.h'
#include <rte_eventdev_core.h>(yes that one is in single quotes, don't come for me, that's literally how it's written 🫶)
🧸 Data Structures
these are the lil guys you'll be passing around. learn their names, they're gonna be everywhere:
struct rte_event_dev_infostruct rte_event_dev_configstruct rte_event_queue_confstruct rte_event_port_confstruct rte_eventstruct rte_event_dev_xstats_name
🎀 Macros
bestie this list is LONG. it's giving "the compiler's whole personality". but every single one matters so here we go, no skipping, periodt.
🦋 dev capability bits
these are the flags a device uses to say "yeah I can do that" — you check them, you don't set them:
#define RTE_EVENT_DEV_CAP_QUEUE_QOS RTE_BIT32(0)#define RTE_EVENT_DEV_CAP_EVENT_QOS RTE_BIT32(1)#define RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED RTE_BIT32(2)#define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES RTE_BIT32(3)#define RTE_EVENT_DEV_CAP_BURST_MODE RTE_BIT32(4)#define RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE RTE_BIT32(5)#define RTE_EVENT_DEV_CAP_NONSEQ_MODE RTE_BIT32(6)#define RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK RTE_BIT32(7)#define RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT RTE_BIT32(8)#define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID RTE_BIT32(9)#define RTE_EVENT_DEV_CAP_MAINTENANCE_FREE RTE_BIT32(10)#define RTE_EVENT_DEV_CAP_RUNTIME_QUEUE_ATTR RTE_BIT32(11)#define RTE_EVENT_DEV_CAP_PROFILE_LINK RTE_BIT32(12)#define RTE_EVENT_DEV_CAP_ATOMIC RTE_BIT32(13)#define RTE_EVENT_DEV_CAP_ORDERED RTE_BIT32(14)#define RTE_EVENT_DEV_CAP_PARALLEL RTE_BIT32(15)#define RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ RTE_BIT32(16)#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE RTE_BIT32(17)#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE RTE_BIT32(18)#define RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE RTE_BIT32(19)#define RTE_EVENT_DEV_CAP_PRESCHEDULE_EXPLICIT RTE_BIT32(20)
💜 priority ranges
the actual priority scale, from screaming-urgent to "whenever you feel like it":
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0#define RTE_EVENT_DEV_PRIORITY_NORMAL 128#define RTE_EVENT_DEV_PRIORITY_LOWEST 255
🌸 queue weight + affinity ranges
#define RTE_EVENT_QUEUE_WEIGHT_HIGHEST 255#define RTE_EVENT_QUEUE_WEIGHT_LOWEST 0#define RTE_EVENT_QUEUE_AFFINITY_HIGHEST 255#define RTE_EVENT_QUEUE_AFFINITY_LOWEST 0
🔥 dev attribute ids
#define RTE_EVENT_DEV_ATTR_PORT_COUNT 0#define RTE_EVENT_DEV_ATTR_QUEUE_COUNT 1#define RTE_EVENT_DEV_ATTR_STARTED 2
⭐ dev config flags
#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT RTE_BIT32(0)
🎀 queue config flags
#define RTE_EVENT_QUEUE_CFG_ALL_TYPES RTE_BIT32(0)#define RTE_EVENT_QUEUE_CFG_SINGLE_LINK RTE_BIT32(1)
🦋 queue attribute ids
#define RTE_EVENT_QUEUE_ATTR_PRIORITY 0#define RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_FLOWS 1#define RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_ORDER_SEQUENCES 2#define RTE_EVENT_QUEUE_ATTR_EVENT_QUEUE_CFG 3#define RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE 4#define RTE_EVENT_QUEUE_ATTR_WEIGHT 5#define RTE_EVENT_QUEUE_ATTR_AFFINITY 6
💖 port config flags
#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL RTE_BIT32(0)#define RTE_EVENT_PORT_CFG_SINGLE_LINK RTE_BIT32(1)#define RTE_EVENT_PORT_CFG_HINT_PRODUCER RTE_BIT32(2)#define RTE_EVENT_PORT_CFG_HINT_CONSUMER RTE_BIT32(3)#define RTE_EVENT_PORT_CFG_HINT_WORKER RTE_BIT32(4)#define RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ RTE_BIT32(5)
🎀 port attribute ids
#define RTE_EVENT_PORT_ATTR_ENQ_DEPTH 0#define RTE_EVENT_PORT_ATTR_DEQ_DEPTH 1#define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3#define RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ 4
🧚 scheduling types (the big three, iykyk)
#define RTE_SCHED_TYPE_ORDERED 0#define RTE_SCHED_TYPE_ATOMIC 1#define RTE_SCHED_TYPE_PARALLEL 2
🌈 event types
#define RTE_EVENT_TYPE_ETHDEV 0x0#define RTE_EVENT_TYPE_CRYPTODEV 0x1#define RTE_EVENT_TYPE_TIMER 0x2#define RTE_EVENT_TYPE_CPU 0x3#define RTE_EVENT_TYPE_ETH_RX_ADAPTER 0x4#define RTE_EVENT_TYPE_DMADEV 0x5#define RTE_EVENT_TYPE_VECTOR 0x8
and the vector combos, which are literally just OR-ing the vector bit in:
#define RTE_EVENT_TYPE_ETHDEV_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_ETHDEV)#define RTE_EVENT_TYPE_CPU_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_CPU)#define RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_ETH_RX_ADAPTER)#define RTE_EVENT_TYPE_CRYPTODEV_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_CRYPTODEV)
and the ceiling:
#define RTE_EVENT_TYPE_MAX 0x10
💅 event op types — the three moods
#define RTE_EVENT_OP_NEW 0#define RTE_EVENT_OP_FORWARD 1#define RTE_EVENT_OP_RELEASE 2
🦋 eth rx adapter caps
#define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT 0x1#define RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ 0x2#define RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID 0x4#define RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR 0x8
⏰ timer adapter caps
#define RTE_EVENT_TIMER_ADAPTER_CAP_INTERNAL_PORT RTE_BIT32(0)#define RTE_EVENT_TIMER_ADAPTER_CAP_PERIODIC RTE_BIT32(1)
🔐 crypto adapter caps
#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND 0x4#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8#define RTE_EVENT_CRYPTO_ADAPTER_CAP_EVENT_VECTOR 0x10
🌟 dma adapter caps
#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_VCHAN_EV_BIND 0x4
📤 eth tx adapter caps
#define RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT 0x1#define RTE_EVENT_ETH_TX_ADAPTER_CAP_EVENT_VECTOR 0x2
🎯 vector adapter caps
#define RTE_EVENT_VECTOR_ADAPTER_CAP_INTERNAL_PORT 0x1
🍓 xstats + maintenance ops
#define RTE_EVENT_DEV_XSTATS_NAME_SIZE 64#define RTE_EVENT_DEV_MAINT_OP_FLUSH (1 << 0)
🌸 Typedefs
two callback shapes, both void-returning, both taking a dev_id, an event and your arg:
typedef void(* rte_eventdev_port_flush_t) (uint8_t dev_id, struct rte_event event, void *arg)typedef void(* rte_eventdev_stop_flush_t) (uint8_t dev_id, struct rte_event event, void *arg)
🦋 Enumerations
enum rte_event_dev_preschedule_type { RTE_EVENT_PRESCHEDULE_NONE, RTE_EVENT_PRESCHEDULE, RTE_EVENT_PRESCHEDULE_ADAPTIVE }enum rte_event_dev_xstats_mode
💜 Functions
okay this is the whole menu. don't panic. we go in groups 💖
🎀 device discovery + config
uint8_t rte_event_dev_count (void)int rte_event_dev_get_dev_id (const char *name)int rte_event_dev_socket_id (uint8_t dev_id)int rte_event_dev_info_get (uint8_t dev_id, struct rte_event_dev_info *dev_info)int rte_event_dev_attr_get (uint8_t dev_id, uint32_t attr_id, uint32_t *attr_value)int rte_event_dev_configure (uint8_t dev_id, const struct rte_event_dev_config *dev_conf)
🌸 queue era
int rte_event_queue_default_conf_get (uint8_t dev_id, uint8_t queue_id, struct rte_event_queue_conf *queue_conf)int rte_event_queue_setup (uint8_t dev_id, uint8_t queue_id, const struct rte_event_queue_conf *queue_conf)int rte_event_queue_attr_get (uint8_t dev_id, uint8_t queue_id, uint32_t attr_id, uint32_t *attr_value)int rte_event_queue_attr_set (uint8_t dev_id, uint8_t queue_id, uint32_t attr_id, uint64_t attr_value)
🦋 port era
int rte_event_port_default_conf_get (uint8_t dev_id, uint8_t port_id, struct rte_event_port_conf *port_conf)int rte_event_port_setup (uint8_t dev_id, uint8_t port_id, const struct rte_event_port_conf *port_conf)void rte_event_port_quiesce (uint8_t dev_id, uint8_t port_id, rte_eventdev_port_flush_t release_cb, void *args)int rte_event_port_attr_get (uint8_t dev_id, uint8_t port_id, uint32_t attr_id, uint32_t *attr_value)
⭐ start / stop / close (the lifecycle girlies)
int rte_event_dev_start (uint8_t dev_id)void rte_event_dev_stop (uint8_t dev_id)int rte_event_dev_stop_flush_callback_register (uint8_t dev_id, rte_eventdev_stop_flush_t callback, void *userdata)int rte_event_dev_close (uint8_t dev_id)
🫶 the vector struct (yes it's listed here, just roll with it)
struct __rte_aligned (16) rte_event_vector
🌈 adapter capability checks
int rte_event_eth_rx_adapter_caps_get (uint8_t dev_id, uint16_t eth_port_id, uint32_t *caps)int rte_event_timer_adapter_caps_get (uint8_t dev_id, uint32_t *caps)int rte_event_crypto_adapter_caps_get (uint8_t dev_id, uint8_t cdev_id, uint32_t *caps)__rte_experimental int rte_event_dma_adapter_caps_get (uint8_t dev_id, uint8_t dmadev_id, uint32_t *caps)int rte_event_eth_tx_adapter_caps_get (uint8_t dev_id, uint16_t eth_port_id, uint32_t *caps)
heads up, that dma one is tagged __rte_experimental — experimental APIs can change or vanish, so don't build your whole personality on it 🙈
💅 timeouts + linking
int rte_event_dequeue_timeout_ticks (uint8_t dev_id, uint64_t ns, uint64_t *timeout_ticks)int rte_event_port_link (uint8_t dev_id, uint8_t port_id, const uint8_t queues[], const uint8_t priorities[], uint16_t nb_links)int rte_event_port_unlink (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint16_t nb_unlinks)__rte_experimental int rte_event_port_profile_links_set (uint8_t dev_id, uint8_t port_id, const uint8_t queues[], const uint8_t priorities[], uint16_t nb_links, uint8_t profile_id)__rte_experimental int rte_event_port_profile_unlink (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint16_t nb_unlinks, uint8_t profile_id)int rte_event_port_unlinks_in_progress (uint8_t dev_id, uint8_t port_id)int rte_event_port_links_get (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint8_t priorities[])__rte_experimental int rte_event_port_profile_links_get (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint8_t priorities[], uint8_t profile_id)
the three __rte_experimental profile-link ones are also experimental, same deal — cute but not guaranteed forever ✨
🎀 service, dump, xstats, selftest
int rte_event_dev_service_id_get (uint8_t dev_id, uint32_t *service_id)int rte_event_dev_dump (uint8_t dev_id, FILE *f)int rte_event_dev_xstats_names_get (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id, struct rte_event_dev_xstats_name *xstats_names, uint64_t *ids, unsigned int size)int rte_event_dev_xstats_get (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id, const uint64_t ids[], uint64_t values[], unsigned int n)uint64_t rte_event_dev_xstats_by_name_get (uint8_t dev_id, const char *name, uint64_t *id)int rte_event_dev_xstats_reset (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, int16_t queue_port_id, const uint64_t ids[], uint32_t nb_ids)int rte_event_dev_selftest (uint8_t dev_id)
🧚 mempool + the fast-path static inlines
these are static inline, so they live in your header and get inlined into your hot loop. main character energy fr:
struct rte_mempool * rte_event_vector_pool_create (const char *name, unsigned int n, unsigned int cache_size, uint16_t nb_elem, int socket_id)static uint16_t rte_event_enqueue_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events)static uint16_t rte_event_enqueue_new_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events)static uint16_t rte_event_enqueue_forward_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events)static uint16_t rte_event_dequeue_burst (uint8_t dev_id, uint8_t port_id, struct rte_event ev[], uint16_t nb_events, uint64_t timeout_ticks)static int rte_event_maintain (uint8_t dev_id, uint8_t port_id, int op)static uint8_t rte_event_port_profile_switch (uint8_t dev_id, uint8_t port_id, uint8_t profile_id)static __rte_experimental int rte_event_port_preschedule_modify (uint8_t dev_id, uint8_t port_id, enum rte_event_dev_preschedule_type type)static __rte_experimental void rte_event_port_preschedule (uint8_t dev_id, uint8_t port_id, enum rte_event_dev_preschedule_type type)
those last two carry __rte_experimental too — experimental, so yes, they can move on you 😭
💫 Detailed Description 💫
(that's the next part, bestie — deep breath, we got this 🫶)
okay so picture the ✨traditional✨ DPDK app model for a sec: your app literally sits there polling Ethdev port RX queues looking for work, and processing happens in a run-to-completion kinda way, and after that the packets get transmitted on a Ethdev TX queue. Load gets distributed by statically assigning ports and queues to lcores, and NIC receive-side scaling (RSS), or something similar, is what's used to distribute network flows (and thus the work) on the same port across multiple RX queues. very manual, very DIY 💅
Now in contrast, in an event-driven model (which is what this 'eventdev' library supports, bestie 🌸), incoming packets (or other input events) get fed into an event device, and that device schedules those packets across the available lcores, in accordance with its configuration. And like… this event-driven programming model just hands your app automatic multicore scaling, dynamic load balancing, pipelining, packet order maintenance, synchronization, and prioritization/quality of service. no cap, it's giving main character energy 👑
The Event Device API is composed of two parts:
- The application-oriented Event API — includes functions to setup an event device (configure it, setup its queues, ports and start it), to establish the links between queues and ports to receive events, and so on.
- The driver-oriented Event API — exports a function allowing an event poll Mode Driver (PMD) to register itself as an event device driver. 🫶
✨ Application-oriented Event API ✨
Event device components, and yes I'm putting the whole diagram here because it ate and you need to see it 🎀:
+-----------------+
| +-------------+ |
+-------+ | | flow 0 | |
|Packet | | +-------------+ |
|event | | +-------------+ |
| | | | flow 1 | |port_link(port0, queue0)
+-------+ | +-------------+ | | +--------+
+-------+ | +-------------+ o-----v-----o |dequeue +------+
|Crypto | | | flow n | | | event +------->|Core 0|
|work | | +-------------+ o----+ | port 0 | | |
|done ev| | event queue 0 | | +--------+ +------+
+-------+ +-----------------+ |
+-------+ |
|Timer | +-----------------+ | +--------+
|expiry | | +-------------+ | +------o |dequeue +------+
|event | | | flow 0 | o-----------o event +------->|Core 1|
+-------+ | +-------------+ | +----o port 1 | | |
Event enqueue | +-------------+ | | +--------+ +------+
o-------------> | | flow 1 | | |
enqueue( | +-------------+ | |
queue_id, | | | +--------+ +------+
flow_id, | +-------------+ | | | |dequeue |Core 2|
sched_type, | | flow n | o-----------o event +------->| |
event_type, | +-------------+ | | | port 2 | +------+
subev_type, | event queue 1 | | +--------+
event) +-----------------+ | +--------+
| | |dequeue +------+
+-------+ +-----------------+ | | event +------->|Core n|
|Core | | +-------------+ o-----------o port n | | |
|(SW) | | | flow 0 | | | +--------+ +--+---+
|event | | +-------------+ | | |
+-------+ | +-------------+ | | |
^ | | flow 1 | | | |
| | +-------------+ o------+ |
| | +-------------+ | |
| | | flow n | | |
| | +-------------+ | |
| | event queue n | |
| +-----------------+ |
| |
+-----------------------------------------------------------+Event device: a hardware or software-based event scheduler. the whole vibe 🧚
Event: represents an item of work and is the smallest unit of scheduling. An event carries metadata, such as queue ID, scheduling type, and event priority, and data such as one or more packets or other kinds of buffers. Some examples of events are:
- a software-generated item of work originating from a lcore, perhaps carrying a packet to be processed. 🍓
- a crypto work completion notification.
- a timer expiry notification. ⏰
Event queue: a queue containing events that are to be scheduled by the event device. An event queue contains events of different flows associated with scheduling types, such as atomic, ordered, or parallel. Every single event you give to an event device must have a valid event queue id field in the metadata, to specify on which event queue in the device the event must be placed, for later scheduling. don't skip that part 🙈
Event port: an application's interface into the event dev for enqueue and dequeue operations. Each event port can be linked with one or more event queues for dequeue operations. Enqueue and dequeue from a port is not thread-safe, and the expected use-case is that each port is polled by only a single lcore. [If this is not the case, a suitable synchronization mechanism should be used to prevent simultaneous access from multiple lcores.] To schedule events to an lcore, the event device will schedule them to the event port(s) being polled by that lcore. 💫
NOTE: by default, all the functions of the Event Device API exported by a PMD are non-thread-safe functions, which must not be invoked on the same object in parallel on different logical cores. For instance, the dequeue function of a PMD cannot be invoked in parallel on two logical cores to operate on same event port. Of course, this function can be invoked in parallel by different logical cores on different ports. It is the responsibility of the upper level application to enforce this rule. 😭 pls don't make it weird
In all functions of the Event API, the Event device is designated by an integer >= 0 named the device identifier dev_id. 🎀
The functions exported by the application Event API to setup a device must be invoked in the following order:
rte_event_dev_configure()rte_event_queue_setup()rte_event_port_setup()rte_event_port_link()rte_event_dev_start()
Then, the application can invoke, in any order, the functions exported by the Event API to dequeue events, enqueue events, and link and unlink event queue(s) to event ports. slay, freedom 🌈
Before configuring a device, an application should call rte_event_dev_info_get() to determine the capabilities of the event device, and any queue or port limits of that device. The parameters set in the various device configuration structures may need to be adjusted based on the max values provided in the device information structure returned from the rte_event_dev_info_get() API. An application may use rte_event_queue_default_conf_get() or rte_event_port_default_conf_get() to get the default configuration to set up an event queue or event port by overriding few default values. so convenient, obsessed 💜
If the application wants to change the configuration (i.e. call rte_event_dev_configure(), rte_event_queue_setup(), or rte_event_port_setup()), it must call rte_event_dev_stop() first to stop the device and then do the reconfiguration before calling rte_event_dev_start() again. The schedule, enqueue and dequeue functions should not be invoked when the device is stopped. no exceptions bestie 💀
Finally, an application can close an Event device by invoking the rte_event_dev_close() function. Once closed, a device cannot be reconfigured or restarted. it's over, it's done, periodt.
🦋 Driver-Oriented Event API 🦋
At the Event driver level, Event devices are represented by a generic data structure of type rte_event_dev.
Event devices are dynamically registered during the PCI/SoC device probing phase performed at EAL initialization time. When an Event device is being probed, an rte_event_dev structure is allocated for it and the event_dev_init() function supplied by the Event driver is invoked to properly initialize the device. ✨
The role of the device init function is to reset the device hardware or to initialize the software event driver implementation.
If the device init operation is successful, the device is assigned a device id (dev_id) for application use. Otherwise, the rte_event_dev structure is freed. 😭 rip
Each function of the application Event API invokes a specific function of the PMD that controls the target device designated by its device identifier.
For this purpose, all device-specific functions of an Event driver are supplied through a set of pointers contained in a generic structure of type event_dev_ops. The address of the event_dev_ops structure is stored in the rte_event_dev structure by the device init function of the Event driver, which is invoked during the PCI/SoC device probing phase, as explained earlier. iykyk 🧚
In other words, each function of the Event API simply retrieves the rte_event_dev structure associated with the device identifier and performs an indirect invocation of the corresponding driver function supplied in the event_dev_ops structure of the rte_event_dev structure.
For performance reasons, the addresses of the fast-path functions of the event driver are not contained in the event_dev_ops structure. Instead, they are directly stored at the beginning of the rte_event_dev structure to avoid an extra indirect memory access during their invocation. efficiency queen 👑
🌸 Event Enqueue, Dequeue and Scheduling 🌸
RTE event device drivers do not use interrupts for enqueue or dequeue operation. Instead, Event drivers export Poll-Mode enqueue and dequeue functions to applications. poll mode only, we don't do naps here 😤
The events are injected to event device through enqueue operation by event producers in the system. The typical event producers are ethdev subsystem for generating packet events, CPU(SW) for generating events based on different stages of application processing, cryptodev for generating crypto work completion notification etc.
The dequeue operation gets one or more events from the event ports. The application processes the events and sends them to a downstream event queue through rte_event_enqueue_burst(), if it is an intermediate stage of event processing. On the final stage of processing, the application may use the Tx adapter API for maintaining the event ingress order while sending the packet/event on the wire via NIC Tx. 🫶 that's the whole loop, you got this 💅
okay so where do events actually get scheduled to ports? It depends on the device, bestie. For hardware devices, scheduling happens asynchronously, with zero software intervention. Software schedulers can be either distributed — each worker thread schedules events to its own port — or centralized — one dedicated thread schedules to all ports. Distributed software schedulers do the scheduling inside the enqueue or dequeue functions, while centralized software schedulers need a dedicated service core for scheduling. If the RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag is not present, that means the device is centralized and therefore needs a dedicated scheduling thread (generally an RTE service that should be mapped to one or more service cores) that repeatedly calls the software-specific scheduling function. iykyk ✨
An event-driven worker thread has this typical workflow on the fastpath:
while (1) {
rte_event_dequeue_burst(...);
(event processing)
rte_event_enqueue_burst(...);
}Definition in file rte_eventdev.h.
🎀 Macro Definition Documentation 🎀
🦋 #define RTE_EVENT_DEV_CAP_QUEUE_QOS RTE_BIT32(0) 🦋
Event scheduling prioritization is based on the priority and weight associated with each event queue. Periodt.
Events from a queue with the highest priority are scheduled first. If the queues have the same priority, the weight of the queues is considered so a queue gets selected in a weighted round robin fashion. Subsequent dequeue calls from an event port could see events from the same event queue if that queue is configured with an affinity count. Affinity count is the number of subsequent dequeue calls in which an event port should use the same event queue if the queue is non-empty.
NOTE: a device may use both queue prioritization and event prioritization (the RTE_EVENT_DEV_CAP_EVENT_QOS capability) when making packet scheduling decisions.
See also
rte_event_queue_setup()rte_event_queue_attr_set()
Definition at line 270 of file rte_eventdev.h.
🌸 #define RTE_EVENT_DEV_CAP_EVENT_QOS RTE_BIT32(1) 🌸
Event scheduling prioritization is based on the priority associated with each event. Obsessed.
Priority of each event is supplied in the rte_event structure on each enqueue operation. If this capability is not set, the priority field of the event structure is ignored for each event.
NOTE: a device may use both queue prioritization (the RTE_EVENT_DEV_CAP_QUEUE_QOS capability) and event prioritization when making packet scheduling decisions.
See also
rte_event_enqueue_burst()
Definition at line 284 of file rte_eventdev.h.
💜 #define RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED RTE_BIT32(2) 💜
Event device operates in distributed scheduling mode.
In distributed scheduling mode, event scheduling happens in HW or in rte_event_dequeue_burst() / rte_event_enqueue_burst(), or the combination of those two. If the flag is not set, then eventdev is centralized and therefore needs a dedicated service core that acts as a scheduling thread.
See also
rte_event_dev_service_id_get()
Definition at line 294 of file rte_eventdev.h.
🫶 #define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES RTE_BIT32(3) 🫶
Event device is capable of accepting enqueued events of any type advertised as supported by the device, to all destination queues. slay
When this capability is set, and the RTE_EVENT_QUEUE_CFG_ALL_TYPES flag is set in rte_event_queue_conf::event_queue_cfg, the 'schedule_type' field of the rte_event_queue_conf structure is ignored when a queue is being configured. Instead, the 'sched_type' field of each event enqueued is used to select the scheduling to be performed on that event.
If this capability is not set, or the configuration flag is not set, the queue only supports events of the RTE_SCHED_TYPE_ type specified in the rte_event_queue_conf structure at the time of configuration. The behaviour when events of other scheduling types are sent to the queue is undefined — not cute, don’t do it.
See also
RTE_EVENT_QUEUE_CFG_ALL_TYPESRTE_SCHED_TYPE_ATOMICRTE_SCHED_TYPE_ORDEREDRTE_SCHED_TYPE_PARALLELrte_event_queue_conf.event_queue_cfgrte_event_queue_conf.schedule_typerte_event_enqueue_burst()
Definition at line 318 of file rte_eventdev.h.
⭐ #define RTE_EVENT_DEV_CAP_BURST_MODE RTE_BIT32(4) ⭐
Event device is capable of operating in burst mode for enqueue (forward, release) and dequeue operation.
If this capability is not set, the application can still use rte_event_dequeue_burst() and rte_event_enqueue_burst(), but the PMD accepts or returns only one event at a time. lowkey fine, just not bursty.
See also
rte_event_dequeue_burst()rte_event_enqueue_burst()
Definition at line 329 of file rte_eventdev.h.
🦋 #define RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE RTE_BIT32(5) 🦋
Event device ports support disabling the implicit release feature, where the port would release all unreleased events in its dequeue operation. the way that works is actually kind of iconic
If this capability is set and the port is configured with implicit release disabled, the application is responsible for explicitly releasing events using either the RTE_EVENT_OP_FORWARD or the RTE_EVENT_OP_RELEASE event enqueue operations. you have to actually do it, bestie.
See also
rte_event_dequeue_burst()rte_event_enqueue_burst()
Definition at line 341 of file rte_eventdev.h.
🌈 #define RTE_EVENT_DEV_CAP_NONSEQ_MODE RTE_BIT32(6) 🌈
Event device is capable of operating in non-sequential mode.
The path of the event is not necessary to be sequential. The application can change the path of an event at runtime, and events may be sent to queues in any order.
If the flag is not set, then each event will follow a path from queue 0 to queue 1 to queue 2, etc. The eventdev will return an error when the application enqueues an event for a qid which is not the next in the sequence. so no skipping the line, okay?
Definition at line 353 of file rte_eventdev.h.
🎀 #define RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK RTE_BIT32(7) 🎀
Event device is capable of reconfiguring the queue/port link at runtime.
If the flag is not set, the eventdev queue/port link can only be configured during initialization, or by stopping the device and then later restarting it after reconfiguration.
See also
rte_event_port_link()rte_event_port_unlink()
Definition at line 364 of file rte_eventdev.h.
💖 #define RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT RTE_BIT32(8) 💖
Event device is capable of setting up links between multiple queues and a single port.
If the flag is not set, each port may only be linked to a single queue, and so can only receive events from that queue. However, each queue may be linked to multiple ports. so queues can be shared, but ports can’t queue-hop without this.
See also
rte_event_port_link()
Definition at line 374 of file rte_eventdev.h.
🦋 #define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID RTE_BIT32(9) 🦋
Event device preserves the flow ID from the enqueued event to the dequeued event. we love continuity.
If this flag is not set, the content of the flow-id field in dequeued events is implementation dependent.
See also
rte_event_dequeue_burst()
Definition at line 383 of file rte_eventdev.h.
✨ #define RTE_EVENT_DEV_CAP_MAINTENANCE_FREE RTE_BIT32(10) ✨
Event device does not require calls to rte_event_maintain().
An event device that does not set this flag requires calls to rte_event_maintain() during periods when neither rte_event_dequeue_burst() nor rte_event_enqueue_burst() are called on a port. This will allow the event device to perform internal processing, such as flushing buffered events, return credits to a global pool, or process signaling related to load balancing. basically it needs its little maintenance moment.
See also
rte_event_maintain()
Definition at line 396 of file rte_eventdev.h.
🫶 #define RTE_EVENT_DEV_CAP_RUNTIME_QUEUE_ATTR RTE_BIT32(11) 🫶
Event device is capable of changing the queue attributes at runtime, i.e. after the rte_event_queue_setup() or rte_event_dev_start() call sequence.
If this flag is not set, event queue attributes can only be configured during rte_event_queue_setup().
See also
rte_event_queue_setup()
Definition at line 406 of file rte_eventdev.h.
🌸 #define RTE_EVENT_DEV_CAP_PROFILE_LINK RTE_BIT32(12) 🌸
Event device is capable of supporting multiple link profiles per event port.
When set, the value of rte_event_dev_info::max_profiles_per_port is greater than one, and multiple profiles may be configured and then switched at runtime. If not set, only a single profile may be configured, which may itself be runtime adjustable (if RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK is set). profile switching is giving main character energy.
See also
rte_event_port_profile_links_set()rte_event_port_profile_links_get()rte_event_port_profile_switch()RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK
Definition at line 420 of file rte_eventdev.h.
💜 #define RTE_EVENT_DEV_CAP_ATOMIC RTE_BIT32(13) 💜
Event device is capable of atomic scheduling. When this flag is set, the application can configure queues with scheduling type atomic on this event device.
See also
RTE_SCHED_TYPE_ATOMIC
Definition at line 428 of file rte_eventdev.h.
⭐ #define RTE_EVENT_DEV_CAP_ORDERED RTE_BIT32(14) ⭐
Event device is capable of ordered scheduling. When this flag is set, the application can configure queues with scheduling type ordered on this event device.
See also
RTE_SCHED_TYPE_ORDERED
Definition at line 436 of file rte_eventdev.h.
🌈 #define RTE_EVENT_DEV_CAP_PARALLEL RTE_BIT32(15) 🌈
Event device is capable of parallel scheduling. When this flag is set, the application can configure queues with scheduling type parallel on this event device.
See also
RTE_SCHED_TYPE_PARALLEL
Definition at line 444 of file rte_eventdev.h.
🔥 #define RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ RTE_BIT32(16) 🔥
Event device is capable of independent enqueue. A new capability, RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ, will indicate that Eventdev supports the enqueue in any order or specifically in a different order than the dequeue.
Eventdev PMD can either dequeue events in the changed order in which they are enqueued or restore the original order before sending them to the underlying hardware device. A flag is provided during the port configuration to inform Eventdev PMD that the application intends to use an independent enqueue order on a particular port. Note that this capability only matters for eventdevs supporting burst mode. so if you’re not in burst mode, this whole vibe is not your problem.
When an implicit release is enabled on a port, Eventdev PMD will also handle the insertion of RELEASE events in place of dropped events. The independent enqueue feature only applies to FORWARD and RELEASE events. New events (op=RTE_EVENT_OP_NEW) will be dequeued in the order the application enqueues them and do not maintain any order relative to FORWARD/RELEASE events. FORWARD vs NEW relaxed ordering only applies to ports that have enabled independent enqueue feature. read that twice, bestie — it’s important.
Definition at line 463 of file rte_eventdev.h.
RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE
#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE RTE_BIT32(17)bestie, this device supports event pre-scheduling ✨
So when this capability is there, your app can turn on event pre-scheduling on the event device and it'll, like, pre-schedule events onto an event port when rte_event_dequeue_burst() gets issued. The pre-schedule process kicks off with the rte_event_dequeue_burst() call, and the pre-scheduled events come back to you on the next rte_event_dequeue_burst() call. Delayed gratification, but make it throughput 💅
See also: rte_event_dev_configure()
Definition at line 475 of file rte_eventdev.h.
RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE
#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE RTE_BIT32(18)the adaptive version of pre-scheduling, and honestly? it's giving smart 🌸
When this capability is available, your app can enable adaptive pre-scheduling on the event device, where events get pre-scheduled when there are no forward progress constraints with the currently held flow contexts. Like, only when it's safe to vibe forward. Same deal as before: the pre-schedule process starts with the rte_event_dequeue_burst() call, and the pre-scheduled events are returned on the next rte_event_dequeue_burst() call 🎀
See also: rte_event_dev_configure()
Definition at line 487 of file rte_eventdev.h.
RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE
#define RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE RTE_BIT32(19)per-port pre-scheduling, no cap 🔥
When this flag is set, the event device lets you control event pre-scheduling at the granularity of a single event port. One port can pre-schedule, another can chill — your call.
See also: rte_event_dev_configure(), rte_event_port_preschedule_modify()
Definition at line 497 of file rte_eventdev.h.
RTE_EVENT_DEV_CAP_PRESCHEDULE_EXPLICIT
#define RTE_EVENT_DEV_CAP_PRESCHEDULE_EXPLICIT RTE_BIT32(20)explicit pre-scheduling — you're the one in charge, main character energy 👑
When this flag is set, the application can issue a pre-schedule request on an event port. Yes, on purpose, when you say so.
See also: rte_event_port_preschedule()
Definition at line 506 of file rte_eventdev.h.
RTE_EVENT_DEV_PRIORITY_HIGHEST
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0the highest priority level for events and queues. Zero equals top of the food chain 🧚✨
See also: rte_event_queue_setup(), rte_event_enqueue_burst(), rte_event_port_link()
Definition at line 515 of file rte_eventdev.h.
RTE_EVENT_DEV_PRIORITY_NORMAL
#define RTE_EVENT_DEV_PRIORITY_NORMAL 128the normal priority level for events and queues — the default-ish, middle-of-the-road, absolutely unproblematic 128 🎀
See also: rte_event_queue_setup(), rte_event_enqueue_burst(), rte_event_port_link()
Definition at line 522 of file rte_eventdev.h.
RTE_EVENT_DEV_PRIORITY_LOWEST
#define RTE_EVENT_DEV_PRIORITY_LOWEST 255the lowest priority level for events and queues. 255 is where things go when they can wait, bestie 😭
See also: rte_event_queue_setup(), rte_event_enqueue_burst(), rte_event_port_link()
Definition at line 529 of file rte_eventdev.h.
RTE_EVENT_QUEUE_WEIGHT_HIGHEST
#define RTE_EVENT_QUEUE_WEIGHT_HIGHEST 255the highest weight an event queue can have. 255, maxed out, hitting different 💅
See also: rte_event_queue_attr_get(), rte_event_queue_attr_set()
Definition at line 537 of file rte_eventdev.h.
RTE_EVENT_QUEUE_WEIGHT_LOWEST
#define RTE_EVENT_QUEUE_WEIGHT_LOWEST 0the lowest weight of an event queue — all the way down at 0 🦋
See also: rte_event_queue_attr_get(), rte_event_queue_attr_set()
Definition at line 543 of file rte_eventdev.h.
RTE_EVENT_QUEUE_AFFINITY_HIGHEST
#define RTE_EVENT_QUEUE_AFFINITY_HIGHEST 255the highest scheduling affinity an event queue can have — 255, bestie ✨
See also: rte_event_queue_attr_get(), rte_event_queue_attr_set()
Definition at line 551 of file rte_eventdev.h.
RTE_EVENT_QUEUE_AFFINITY_LOWEST
#define RTE_EVENT_QUEUE_AFFINITY_LOWEST 0the lowest scheduling affinity of an event queue — 0 is the floor 🌈
See also: rte_event_queue_attr_get(), rte_event_queue_attr_set()
Definition at line 557 of file rte_eventdev.h.
RTE_EVENT_DEV_ATTR_PORT_COUNT
#define RTE_EVENT_DEV_ATTR_PORT_COUNT 0the count of ports 🫶
Definition at line 709 of file rte_eventdev.h.
RTE_EVENT_DEV_ATTR_QUEUE_COUNT
#define RTE_EVENT_DEV_ATTR_QUEUE_COUNT 1the count of queues 🎀
Definition at line 713 of file rte_eventdev.h.
RTE_EVENT_DEV_ATTR_STARTED
#define RTE_EVENT_DEV_ATTR_STARTED 2the status of the device: zero for stopped, non-zero for started. Are we live or are we napping, that's the question 💀
Definition at line 717 of file rte_eventdev.h.
RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT RTE_BIT32(0)this one overrides the global dequeue_timeout_ns and uses a per dequeue timeout, measured in ns ⏱️ so each dequeue can have its own clock, iykyk
See also: rte_event_dequeue_timeout_ticks(), rte_event_dequeue_burst()
Definition at line 740 of file rte_eventdev.h.
RTE_EVENT_QUEUE_CFG_ALL_TYPES
#define RTE_EVENT_QUEUE_CFG_ALL_TYPES RTE_BIT32(0)okay so this one lets events with schedule types ATOMIC, ORDERED, and PARALLEL all be enqueued to this queue 🔥
The scheduling type used is the one specified in each individual event. Important bit: this flag can only be set when you're configuring queues on devices that report the RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES capability.
Without this flag? Only events with the specific scheduling type configured at queue setup can be sent to the queue. No mixing, no chaos 🌸
See also: RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES, RTE_SCHED_TYPE_ORDERED, RTE_SCHED_TYPE_ATOMIC, RTE_SCHED_TYPE_PARALLEL, rte_event_enqueue_burst()
Definition at line 890 of file rte_eventdev.h.
RTE_EVENT_QUEUE_CFG_SINGLE_LINK
#define RTE_EVENT_QUEUE_CFG_SINGLE_LINK RTE_BIT32(1)this event queue links to exactly one event port. Monogamous queue 💅
No load-balancing of events is performed, because all events sent to this queue end up at the same event port. And heads up: the number of queues you set this flag on has to be configured at device configuration time, by setting the rte_event_dev_config::nb_single_link_event_port_queues parameter appropriately.
Also, this flag serves as a hint only — any devices without specific support for single-link queues can fall back automatically to using regular queues with a single destination port. Flexible king behavior 👑
See also: rte_event_dev_info.max_single_link_event_port_queue_pairs, rte_event_dev_config.nb_single_link_event_port_queues, rte_event_port_setup(), rte_event_port_link()
Definition at line 908 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_PRIORITY
#define RTE_EVENT_QUEUE_ATTR_PRIORITY 0queue attribute id for the priority of the queue ✨
Definition at line 1041 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_FLOWS
#define RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_FLOWS 1queue attribute id for the number of atomic flows configured for the queue 🦋
Definition at line 1045 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_ORDER_SEQUENCES
#define RTE_EVENT_QUEUE_ATTR_NB_ATOMIC_ORDER_SEQUENCES 2queue attribute id for the number of atomic order sequences configured for the queue 🎀
Definition at line 1049 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_EVENT_QUEUE_CFG
#define RTE_EVENT_QUEUE_ATTR_EVENT_QUEUE_CFG 3queue attribute id for the configuration flags of the queue 💜
Definition at line 1053 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE
#define RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE 4queue attribute id for the schedule type of the queue 🌈
Definition at line 1057 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_WEIGHT
#define RTE_EVENT_QUEUE_ATTR_WEIGHT 5queue attribute id for the weight of the queue ⭐
Definition at line 1061 of file rte_eventdev.h.
RTE_EVENT_QUEUE_ATTR_AFFINITY
#define RTE_EVENT_QUEUE_ATTR_AFFINITY 6queue attribute id for the affinity of the queue 💖
Definition at line 1065 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL
#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL RTE_BIT32(0)configure the port to not release outstanding events in rte_event_dev_dequeue_burst() 🙈
If it's set, then every single event you receive through the port must be explicitly released with RTE_EVENT_OP_RELEASE or RTE_EVENT_OP_FORWARD. And, critically: it must be unset if the device isn't RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable. Like, don't set it, bestie, it's not allowed there 😭
Definition at line 1123 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_SINGLE_LINK
#define RTE_EVENT_PORT_CFG_SINGLE_LINK RTE_BIT32(1)this event port links to only one event queue — and the queue it links with should be similarly configured with the RTE_EVENT_QUEUE_CFG_SINGLE_LINK flag. Matching set, we love to see it 🎀
See also: RTE_EVENT_QUEUE_CFG_SINGLE_LINK, rte_event_port_setup(), rte_event_port_link()
Definition at line 1131 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_HINT_PRODUCER
#define RTE_EVENT_PORT_CFG_HINT_PRODUCER RTE_BIT32(2)a hint that this event port will primarily enqueue events to the system 💅
A PMD can optimize its internal workings by assuming this port is mostly gonna enqueue NEW events. But — and this matters — this flag is only a hint, so PMDs must operate under the assumption that any port can enqueue an event with any type of op. No assumptions, babe 🫶
See also: rte_event_port_setup()
Definition at line 1141 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_HINT_CONSUMER
#define RTE_EVENT_PORT_CFG_HINT_CONSUMER RTE_BIT32(3)a hint that this event port will primarily dequeue events from the system 🍓
A PMD can optimize its internal workings by assuming this port is mostly gonna consume events, and not enqueue NEW or FORWARD events. Again: only a hint, so PMDs must assume any port can enqueue an event with any type of op ✨
See also: rte_event_port_setup()
Definition at line 1152 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_HINT_WORKER
#define RTE_EVENT_PORT_CFG_HINT_WORKER RTE_BIT32(4)a hint that this event port will primarily pass existing events through 🔁
A PMD can optimize its internals by assuming this port is mostly going to FORWARD events, and not enqueue NEW or RELEASE events often. And yeah, same disclaimer: only a hint, PMDs must assume any port can enqueue an event with any type of op 💜
See also: rte_event_port_setup()
Definition at line 1163 of file rte_eventdev.h.
RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ
#define RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ RTE_BIT32(5)flag to enable independent enqueue 🔥
This one must not be set if the device isn't RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ capable — fr fr, don't do it. What it gives you: the app can enqueue RTE_EVENT_OP_FORWARD or RTE_EVENT_OP_RELEASE in an order different than the order the events were dequeued from the event device, while still maintaining RTE_SCHED_TYPE_ATOMIC or RTE_SCHED_TYPE_ORDERED semantics. Out-of-order enqueue, in-order vibes, iconic ✨
Note that this flag only matters for Eventdevs supporting burst mode 👑
See also: rte_event_port_setup()
Definition at line 1175 of file rte_eventdev.h.
RTE_EVENT_PORT_ATTR_ENQ_DEPTH
#define RTE_EVENT_PORT_ATTR_ENQ_DEPTH 0port attribute id for the maximum size of a burst enqueue operation supported on a port 📦
Definition at line 1307 of file rte_eventdev.h.
RTE_EVENT_PORT_ATTR_DEQ_DEPTH
#define RTE_EVENT_PORT_ATTR_DEQ_DEPTH 1port attribute id for the maximum size of a dequeue burst that can be returned from a port 🎀
Definition at line 1311 of file rte_eventdev.h.
RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD
#define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2port attribute id for the new event threshold of the port ⚠️
Once the number of events in the system exceeds this threshold, the enqueue of NEW-type events will fail. So like, mind the limit bestie, it's real 😭
Definition at line 1317 of file rte_eventdev.h.
RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE
#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3port attribute id for the implicit release disable attribute of the port 🌸
Definition at line 1321 of file rte_eventdev.h.
RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ
#define RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ 4port attribute id for the Independent Enqueue feature 🦋
Definition at line 1325 of file rte_eventdev.h.
RTE_SCHED_TYPE_ORDERED
#define RTE_SCHED_TYPE_ORDERED 0Ordered scheduling — and okay hold that thought, because RTE_SCHED_TYPE_ORDERED being 0 is literally where the next bit of this page picks up 💅
okay so events from an ordered flow of an event queue can be scheduled to multiple ports for concurrent processing while maintaining the original event order, i.e. the order in which they were first enqueued to that queue. This scheme allows events pertaining to the same, potentially large, flow to be processed in parallel on multiple cores without incurring any application-level order restoration logic overhead.
After events are dequeued from a set of ports, as those events are re-enqueued to another queue (with the op field set to RTE_EVENT_OP_FORWARD), the event device restores the original event order — including events returned from all ports in the set — before the events are placed on the destination queue, for subsequent scheduling to ports.
Any events not forwarded i.e. dropped explicitly via RELEASE or implicitly released by the next dequeue operation on a port, are skipped by the reordering stage and do not affect the reordering of other returned events.
Any NEW events sent on a port are not ordered with respect to FORWARD events sent on the same port, since they have no original event order. They also are not ordered with respect to NEW events enqueued on other ports. However, NEW events to the same destination queue from the same port are guaranteed to be enqueued in the order they were submitted via rte_event_enqueue_burst().
NOTE: In restoring event order of forwarded events, the eventdev API guarantees that all events from the same flow (i.e. samerte_event::flow_id,rte_event::priorityandrte_event::queue_id) will be put in the original order before being forwarded to the destination queue. Some eventdevs may implement stricter ordering to achieve this aim, for example, restoring the order across all flows dequeued from the same ORDERED queue.
See also
rte_event_queue_setup(),rte_event_dequeue_burst(),RTE_EVENT_OP_RELEASE
Definition at line 1535 of file rte_eventdev.h.
🦋 #define RTE_SCHED_TYPE_ATOMIC 1
Atomic scheduling — bestie, it’s giving exclusive access 💅
Events from an atomic flow, identified by a combination of rte_event::flow_id, rte_event::queue_id and rte_event::priority, can be scheduled only to a single port at a time. The port is guaranteed to have exclusive (atomic) access to the associated flow context, which enables the user to avoid SW synchronization. Atomic flows also maintain event ordering since only one port at a time can process events from each flow of an event queue, and events within a flow are not reordered within the scheduler.
An atomic flow is locked to a port when events from that flow are first scheduled to that port. That lock remains in place until the application calls rte_event_dequeue_burst() from the same port, which implicitly releases the lock (if RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL flag is not set). User may allow the scheduler to release the lock earlier than that by invoking rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE operation for each event from that flow.
NOTE: Where multiple events from the same queue and atomic flow are scheduled to a port, the lock for that flow is only released once the last event from the flow is released, or forwarded to another queue. So long as there is at least one event from an atomic flow scheduled to a port/core (including any events in the port's dequeue queue, not yet read by the application), that port will hold the synchronization lock for that flow.
See also
rte_event_queue_setup(),rte_event_dequeue_burst(),RTE_EVENT_OP_RELEASE
Definition at line 1562 of file rte_eventdev.h.
🌈 #define RTE_SCHED_TYPE_PARALLEL 2
Parallel scheduling — the scheduler is free to go off ✨
The scheduler performs priority scheduling, load balancing, etc. functions but does not provide additional event synchronization or ordering. It is free to schedule events from a single parallel flow of an event queue to multiple events ports for concurrent processing. The application is responsible for flow context synchronization and event ordering (SW synchronization).
See also
rte_event_queue_setup(),rte_event_dequeue_burst()
Definition at line 1575 of file rte_eventdev.h.
🌸 #define RTE_EVENT_TYPE_ETHDEV 0x0
The event generated from ethdev subsystem
Definition at line 1579 of file rte_eventdev.h.
🎀 #define RTE_EVENT_TYPE_CRYPTODEV 0x1
The event generated from crypodev subsystem
Definition at line 1581 of file rte_eventdev.h.
⭐ #define RTE_EVENT_TYPE_TIMER 0x2
The event generated from event timer adapter
Definition at line 1583 of file rte_eventdev.h.
💜 #define RTE_EVENT_TYPE_CPU 0x3
The event generated from cpu for pipelining. Application may use sub_event_type to further classify the event
Definition at line 1587 of file rte_eventdev.h.
🦋 #define RTE_EVENT_TYPE_ETH_RX_ADAPTER 0x4
The event generated from event eth Rx adapter
Definition at line 1589 of file rte_eventdev.h.
🍓 #define RTE_EVENT_TYPE_DMADEV 0x5
The event generated from dma subsystem
Definition at line 1591 of file rte_eventdev.h.
🔥 #define RTE_EVENT_TYPE_VECTOR 0x8
Indicates that event is a vector. All vector event types should be a logical OR of EVENT_TYPE_VECTOR. This simplifies the pipeline design as one can split processing the events between vector events and normal event across event types.
Example: if (ev.event_type & RTE_EVENT_TYPE_VECTOR) { // Classify and handle vector event. } else { // Classify and handle event. }
Definition at line 1603 of file rte_eventdev.h.
🧚 #define RTE_EVENT_TYPE_ETHDEV_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_ETHDEV)
The event vector generated from ethdev subsystem
Definition at line 1606 of file rte_eventdev.h.
🫶 #define RTE_EVENT_TYPE_CPU_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_CPU)
The event vector generated from cpu for pipelining.
Definition at line 1608 of file rte_eventdev.h.
💖 #define RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_ETH_RX_ADAPTER)
The event vector generated from eth Rx adapter.
Definition at line 1611 of file rte_eventdev.h.
🌟 #define RTE_EVENT_TYPE_CRYPTODEV_VECTOR (RTE_EVENT_TYPE_VECTOR | RTE_EVENT_TYPE_CRYPTODEV)
The event vector generated from cryptodev adapter.
Definition at line 1614 of file rte_eventdev.h.
👑 #define RTE_EVENT_TYPE_MAX 0x10
Maximum number of event types
Definition at line 1617 of file rte_eventdev.h.
✨ #define RTE_EVENT_OP_NEW 0
The rte_event::op field must be set to this operation type to inject a new event, i.e. one not previously dequeued, into the event device, to be scheduled for processing.
Definition at line 1624 of file rte_eventdev.h.
💅 #define RTE_EVENT_OP_FORWARD 1
The application must set the rte_event::op field to this operation type to return a previously dequeued event to the event device to be scheduled for further processing.
This event must be enqueued to the same port that the event to be forwarded was dequeued from.
The event's fields, including (but not limited to) flow_id, scheduling type, destination queue, and event payload e.g. mbuf pointer, may all be updated as desired by the application, but the rte_event::impl_opaque field must be kept to the same value as was present when the event was dequeued.
Definition at line 1636 of file rte_eventdev.h.
🎀 #define RTE_EVENT_OP_RELEASE 2
Release the flow context associated with the schedule type.
If current flow's scheduler type method is RTE_SCHED_TYPE_ATOMIC then this operation type hints the scheduler that the user has completed critical section processing for this event in the current atomic context, and that the scheduler may unlock any atomic locks held for this event. If this is the last event from an atomic flow, i.e. all flow locks are released (see RTE_SCHED_TYPE_ATOMIC for details), the scheduler is now allowed to schedule events from that flow from to another port. However, the atomic locks may be still held until the next rte_event_dequeue_burst() call; enqueuing an event with opt type RTE_EVENT_OP_RELEASE is a hint only, allowing the scheduler to release the atomic locks early, but not requiring it to do so.
Early atomic lock release may increase parallelism and thus system performance, but the user needs to design carefully the split into critical vs non-critical sections.
If current flow's scheduler type method is RTE_SCHED_TYPE_ORDERED then this operation type informs the scheduler that the current event has completed processing and will not be returned to the scheduler, i.e. it has been dropped, and so the reordering context for that event should be considered filled.
Events with this operation type must only be enqueued to the same port that the event to be released was dequeued from. The rte_event::impl_opaque field in the release event must have the same value as that in the original dequeued event.
If a dequeued event is re-enqueued with operation type of RTE_EVENT_OP_RELEASE, then any subsequent enqueue of that event — or a copy of it — must be done as event of type RTE_EVENT_OP_NEW, not RTE_EVENT_OP_FORWARD. This is because any context for the originally dequeued event, i.e. atomic locks, or reorder buffer entries, will have been removed or invalidated by the release operation.
Definition at line 1670 of file rte_eventdev.h.
🦋 #define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT 0x1
This flag is sent when the packet transfer mechanism is in HW. Ethdev can send packets to the event device using internal event port.
Definition at line 1806 of file rte_eventdev.h.
🌸 #define RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ 0x2
Adapter supports multiple event queues per ethdev. Every ethdev Rx queue can be connected to a unique event queue.
Definition at line 1810 of file rte_eventdev.h.
🔥 #define RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID 0x4
The application can override the adapter generated flow ID in the event. This flow ID can be specified when adding an ethdev Rx queue to the adapter using the ev.flow_id member.
See also
struct rte_event_eth_rx_adapter_queue_conf::evstruct rte_event_eth_rx_adapter_queue_conf::rx_queue_flags
Definition at line 1817 of file rte_eventdev.h.
🧚 #define RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR 0x8
Adapter supports event vectorization per ethdev.
Definition at line 1819 of file rte_eventdev.h.
⭐ #define RTE_EVENT_TIMER_ADAPTER_CAP_INTERNAL_PORT RTE_BIT32(0)
This flag is set when the timer mechanism is in HW.
Definition at line 1844 of file rte_eventdev.h.
🎀 #define RTE_EVENT_TIMER_ADAPTER_CAP_PERIODIC RTE_BIT32(1)
This flag is set if periodic mode is supported.
Definition at line 1847 of file rte_eventdev.h.
okay so these next caps are still macro lore, and they’re lowkey the adapter capability flags you’ll see in the wild 💅
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW—#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1Flag indicates HW is capable of generating events inRTE_EVENT_OP_NEWenqueue operation. Cryptodev will send packets to the event device as new events using an internal event port.
Definition at line 1871 of file rte_eventdev.h.
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD—#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2Flag indicates HW is capable of generating events inRTE_EVENT_OP_FORWARDenqueue operation. Cryptodev will send packets to the event device as forwarded event using an internal event port.
Definition at line 1878 of file rte_eventdev.h.
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND—#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND 0x4Flag indicates HW is capable of mapping crypto queue pair to event queue.
Definition at line 1883 of file rte_eventdev.h.
RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA—#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8Flag indicates HW/SW supports a mechanism to store and retrieve the private data information along with the crypto session.
Definition at line 1888 of file rte_eventdev.h.
RTE_EVENT_CRYPTO_ADAPTER_CAP_EVENT_VECTOR—#define RTE_EVENT_CRYPTO_ADAPTER_CAP_EVENT_VECTOR 0x10Flag indicates HW is capable of aggregating processed crypto operations intorte_event_vector.
Definition at line 1893 of file rte_eventdev.h.
RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_NEW—#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1Flag indicates HW is capable of generating events inRTE_EVENT_OP_NEWenqueue operation. DMADEV will send packets to the event device as new events using an internal event port.
Definition at line 1924 of file rte_eventdev.h.
RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_FWD—#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2Flag indicates HW is capable of generating events inRTE_EVENT_OP_FORWARDenqueue operation. DMADEV will send packets to the event device as forwarded event using an internal event port.
Definition at line 1931 of file rte_eventdev.h.
RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_VCHAN_EV_BIND—#define RTE_EVENT_DMA_ADAPTER_CAP_INTERNAL_PORT_VCHAN_EV_BIND 0x4Flag indicates HW is capable of mapping DMA vchan to event queue.
Definition at line 1934 of file rte_eventdev.h.
RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT—#define RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT 0x1This flag is sent when the PMD supports a packet transmit callback.
Definition at line 1963 of file rte_eventdev.h.
RTE_EVENT_ETH_TX_ADAPTER_CAP_EVENT_VECTOR—#define RTE_EVENT_ETH_TX_ADAPTER_CAP_EVENT_VECTOR 0x2Indicates that the Tx adapter is capable of handling event vector of mbufs.
Definition at line 1967 of file rte_eventdev.h.
RTE_EVENT_VECTOR_ADAPTER_CAP_INTERNAL_PORT—#define RTE_EVENT_VECTOR_ADAPTER_CAP_INTERNAL_PORT 0x1This flag is set when the vector adapter is capable of generating events using an internal event port.
Definition at line 1993 of file rte_eventdev.h.
RTE_EVENT_DEV_XSTATS_NAME_SIZE—#define RTE_EVENT_DEV_XSTATS_NAME_SIZE 64Maximum name length for extended statistics counters.
Definition at line 2397 of file rte_eventdev.h.
RTE_EVENT_DEV_MAINT_OP_FLUSH—#define RTE_EVENT_DEV_MAINT_OP_FLUSH (1 << 0)Force an immediately flush of any buffered events in the port, potentially at the cost of additional overhead.
See also: rte_event_maintain()
Definition at line 2873 of file rte_eventdev.h.
🫶 Typedef Documentation
🌸 rte_eventdev_port_flush_t
typedef void(* rte_eventdev_port_flush_t) (uint8_t dev_id, struct rte_event
event, void *arg)Callback function prototype that can be passed during rte_event_port_release(), invoked once per a released event.
Definition at line 1269 of file rte_eventdev.h.
🌸 rte_eventdev_stop_flush_t
typedef void(* rte_eventdev_stop_flush_t) (uint8_t dev_id, struct rte_event
event, void *arg)Callback function called during rte_event_dev_stop(), invoked once per flushed event.
Definition at line 1390 of file rte_eventdev.h.
🌈 Enumeration Type Documentation
🧚 rte_event_dev_preschedule_type
Event device pre-schedule type enumeration.
Enumerator
RTE_EVENT_PRESCHEDULE_NONE— Disable pre-schedule across the event device or on a given event port.rte_event_dev_config::preschedule_type,rte_event_port_preschedule_modify()RTE_EVENT_PRESCHEDULE— Enable pre-schedule always across the event device or a given event port.rte_event_dev_config::preschedule_type,rte_event_port_preschedule_modify()- See also:
RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE,RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE
- See also:
RTE_EVENT_PRESCHEDULE_ADAPTIVE— Enable adaptive pre-schedule across the event device or a given event port. Delay issuing pre-schedule until there are no forward progress constraints with the held flow contexts.rte_event_dev_config::preschedule_type,rte_event_port_preschedule_modify()- See also:
RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE,RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE
- See also:
Definition at line 743 of file rte_eventdev.h.
🦋 rte_event_dev_xstats_mode
Selects the component of the eventdev to retrieve statistics from.
Definition at line 2402 of file rte_eventdev.h.
✨ Function Documentation
👑 rte_event_dev_count
uint8_t rte_event_dev_count (void)Get the total number of event devices.
Returns: The total number of usable event devices.
👑 rte_event_dev_get_dev_id
int rte_event_dev_get_dev_id (const char * name)Get the device identifier for the named event device.
Parameters:
name— Event device name to select the event device identifier.
Returns: Event device identifier (dev_id >= 0) on success. Negative error code on failure:
-EINVAL— inputnameparameter is invalid.-ENODEV— no event device found with that name.
👑 rte_event_dev_socket_id
int rte_event_dev_socket_id (uint8_t dev_id)Return the NUMA socket to which a device is connected.
Parameters:
dev_id— The identifier of the device.
Returns: The NUMA socket id to which the device is connected or a default of zero if the socket could not be determined. -EINVAL on error, where the given dev_id value does not correspond to any event device.
👑 rte_event_dev_info_get
int rte_event_dev_info_get (uint8_t dev_id, struct rte_event_dev_info *
dev_info)Retrieve details of an event device's capabilities and configuration limits.
Parameters:
dev_id— The identifier of the device.dev_info— A pointer to a structure of typerte_event_dev_infoto be filled with the information about the device's capabilities.
Returns:
0: Success, information about the event device is present indev_info.<0: Failure, error code returned by the function.-EINVAL— invalid input parameters, e.g. incorrect device id.-ENOTSUP— device does not support returning capabilities information.
👑 rte_event_dev_attr_get
int rte_event_dev_attr_get (uint8_t dev_id, uint32_t attr_id, uint32_t *
attr_value)Get an attribute from a device.
Parameters:
dev_id— Eventdev idattr_id— The attribute ID to retrieveattr_value— A pointer that will be filled in with the attribute value if successful.
Returns:
0: Successfully retrieved attribute value-EINVAL: Invalid device orattr_idprovided, orattr_valueisNULL
👑 rte_event_dev_configure
int rte_event_dev_configure (uint8_t dev_id, const struct
rte_event_dev_config * dev_conf)Configure an event device.
This function must be invoked before any other configuration function in the API, when preparing an event device for application use. This function can also be re-invoked when a device is in the stopped state.
The caller should use rte_event_dev_info_get() to get the capabilities and resource limits for this event device before calling this API. Many values in the dev_conf input parameter are subject to limits given in the device information returned from rte_event_dev_info_get().
Parameters:
dev_id— The identifier of the device to configure.dev_conf— The event device configuration structure.
Returns:
0: Success, device configured.<0: Error code returned by the driver configuration function.-ENOTSUP— device does not support configuration.-EINVAL— invalid input parameter.-EBUSY— device has already been started.
👑 rte_event_queue_default_conf_get
int rte_event_queue_default_conf_get (uint8_t dev_id, uint8_t queue_id,
struct rte_event_queue_conf * queue_conf)Retrieve the default configuration information of an event queue designated by its queue_id from the event driver for an event device.
This function intended to be used in conjunction with rte_event_queue_setup() where caller needs to set up the queue by overriding few default values.
Parameters:
dev_id— The identifier of the device.queue_id— The index of the event queue to get the configuration information. The value must be less thanrte_event_dev_config::nb_event_queuespreviously supplied torte_event_dev_configure().queue_conf— The pointer to the default event queue configuration data.
Returns:
0: Success, driver updates the default event queue configuration data.<0: Error code returned by the driver info get function.
See also: rte_event_queue_setup()
👑 rte_event_queue_setup
int rte_event_queue_setup (uint8_t dev_id, uint8_t queue_id, const struct
rte_event_queue_conf * queue_conf)Allocate and set up an event queue for an event device.
Parameters:
dev_id— The identifier of the device.queue_id— The index of the event queue to setup. The value must be less thanrte_event_dev_config::nb_event_queuespreviously supplied torte_event_dev_configure().queue_conf— The pointer to the configuration data to be used for the event queue.NULLvalue is allowed, in which case default configuration used.
See also: rte_event_queue_default_conf_get()
Returns:
0: Success, event queue correctly set up.<0: event queue configuration failed.
👑 rte_event_queue_attr_get
int rte_event_queue_attr_get (uint8_t dev_id, uint8_t queue_id, uint32_t
attr_id, uint32_t * attr_value)Get an attribute of an event queue.
Parameters:
dev_id— The identifier of the device.queue_id— The index of the event queue to query. The value must be less thanrte_event_dev_config::nb_event_queuespreviously supplied torte_event_dev_configure().attr_id— The attribute ID to retrieve (RTE_EVENT_QUEUE_ATTR_*).attr_value— A pointer that will be filled in with the attribute value if successful.
Returns:
0: Successfully returned value-EINVAL: invalid device, queue orattr_idprovided, orattr_valuewasNULL.-EOVERFLOW: returned whenattr_idis set toRTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPEandRTE_EVENT_QUEUE_CFG_ALL_TYPESis set in the queue configuration flags.
👑 rte_event_queue_attr_set
int rte_event_queue_attr_set (uint8_t dev_id, uint8_t queue_id, uint32_t
attr_id, uint64_t attr_value)Set an event queue attribute.
okay so picking right back up mid-param-list, bestie, no time wasted:
Parameters
dev_id— the identifier of the device 🆔queue_id— the index of the event queue you're configuring. This one has to be less thanrte_event_dev_config::nb_event_queuesthat you already handed torte_event_dev_configure(), or it's not it 💅attr_id— the attribute ID to set, from theRTE_EVENT_QUEUE_ATTR_*family 🎀attr_value— the attribute value to set ✨
Returns
0— successfully set the attribute, we ate 💖<0— failed to set the event queue attribute 😭-EINVAL— invalid device, queue orattr_id🙈-ENOTSUP— device does not support setting the event attribute, so like… no 💀
int rte_event_port_default_conf_get(uint8_t dev_id, uint8_t port_id, struct rte_event_port_conf * port_conf)
Grabs the default configuration info of an event port — the one designated by its port_id — straight from the event driver for an event device 🫶
This is literally meant to be used alongside rte_event_port_setup(), so the caller can set up the port by only overriding a few default values. Fancy minimal effort, we love to see it 🌸
Parameters
dev_id— the identifier of the device 🆔port_id— the index of the event port to get the configuration information for. Must be less thanrte_event_dev_config::nb_event_portsthat you previously supplied torte_event_dev_configure()⭐port_conf— pointer to a struct where the default event port configuration data gets stored 🎀
Returns
0— success, driver updates the default event port configuration data 💖<0— error code returned by the driver info get function:-EINVAL— invalid input parameter 🙈-ENOTSUP— function is not supported for this device 😭
See also — rte_event_port_setup()
int rte_event_port_setup(uint8_t dev_id, uint8_t port_id, const struct rte_event_port_conf * port_conf)
Allocate and set up an event port for an event device. The full glow-up ✨
Parameters
dev_id— the identifier of the device 🆔port_id— the index of the event port to setup. Must be less thanrte_event_dev_config::nb_event_portsthat you previously supplied torte_event_dev_configure()⭐port_conf— pointer to the configuration data used for the port. ANULLvalue is allowed, and in that case the default configuration is used 👑
See also — rte_event_port_default_conf_get()
Returns
0— success, event port correctly set up, slay 🎉<0— port configuration failed:-EINVAL— invalid input parameter 🙈-EBUSY— port already started, bestie it's occupied 💀-ENOTSUP— function not supported on this device, or aNULLpointer passed as theport_confparameter and no default configuration function available for this device 😭-EDQUOT— the application tried to link a queue configured withRTE_EVENT_QUEUE_CFG_SINGLE_LINKto more than one event port. Not allowed, periodt 🚫
void rte_event_port_quiesce(uint8_t dev_id, uint8_t port_id, rte_eventdev_port_flush_t release_cb, void * args)
Quiesce any core-specific resources the event port has consumed 🧘♀️
Event ports are generally coupled with lcores, and a given hardware implementation might require the PMD to store port-specific data in the lcore. So when the app decides to migrate the event port to another lcore, or teardown the current lcore, it may call rte_event_port_quiesce to make sure all the data associated with the event port gets released from the lcore — and yes, that might also include any prefetched events 👀 While releasing the event port from the lcore, this function calls the user-provided flush callback once per event 🦋
Note — invocation of this API does not affect the existing port configuration, so don't panic 💅
Parameters
dev_id— the identifier of the device 🆔port_id— the index of the event port to quiesce. Must be less thanrte_event_dev_config::nb_event_portsthat you previously supplied torte_event_dev_configure()⭐release_cb— callback function invoked once per flushed event 🎀args— argument supplied to the callback 🌸
int rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, uint32_t attr_id, uint32_t * attr_value)
Get an attribute from a port. Simple, iconic, does what it says 💖
Parameters
dev_id— the identifier of the device 🆔port_id— the index of the event port to query. Must be less thanrte_event_dev_config::nb_event_portsthat you previously supplied torte_event_dev_configure()⭐attr_id— the attribute ID to retrieve (RTE_EVENT_PORT_ATTR_*) 🎀attr_value— a pointer that will be filled in with the attribute value if successful ✨
Returns
0— successfully returned value 👑(-EINVAL)— invalid device, port orattr_id, orattr_valuewasNULL💀
int rte_event_dev_start(uint8_t dev_id)
Start an event device. The moment we've all been waiting for 🔥
The device start step is the last one in device setup, and it's what enables the event ports and queues to start accepting events and scheduling them to event ports 🦋
On success, all the basic functions exported by the API (event enqueue, event dequeue and so on) can be invoked. Go off 👑
Parameters
dev_id— event device identifier 🆔
Returns
0— success, device started 🎉-EINVAL— invalid device id provided 🙈-ENOTSUP— device does not support this operation 😭-ESTALE— not all ports of the device are configured ⚠️-ENOLINK— not all queues are linked, which could lead to deadlock 💀
Deadlock is not a vibe. Link your queues, bestie, fr fr.
void rte_event_dev_stop(uint8_t dev_id)
Stop an event device 🛑
This function causes all queued events to be drained, including those residing in event ports. While draining events out of the device, this function calls the user-provided flush callback (if one was registered) once per event 🎀
The device can be restarted with a call to rte_event_dev_start() 💖
careful now — threads that continue to enqueue/dequeue while the device is stopped, or being stopped, will result in undefined behavior. This includes event adapters, which must be stopped prior to stopping the eventdev. No cap, do not do this 😭
Parameters
dev_id— event device identifier 🆔
See also — rte_event_dev_stop_flush_callback_register()
int rte_event_dev_stop_flush_callback_register(uint8_t dev_id, rte_eventdev_stop_flush_t callback, void * userdata)
Registers a callback function to be invoked during rte_event_dev_stop() for each flushed event. Use this to properly dispose of queued events — for example, events containing memory pointers 👀 (memory leaks found dead in a ditch)
The callback function is only registered for the calling process. So the callback must be registered in every process that can call rte_event_dev_stop() ⚠️
Only one callback function may be registered. Each new call replaces the existing registered callback function with the new function passed in 🔄
To unregister a callback, call this function with a NULL callback pointer 🙅♀️
Parameters
dev_id— the identifier of the device 🆔callback— callback function to be invoked once per flushed event. PassNULLto unset any previously-registered callback function 🎀userdata— argument supplied tocallback🌸
Returns
0on success 💖-EINVALifdev_idis invalid 🙈
See also — rte_event_dev_stop()
int rte_event_dev_close(uint8_t dev_id)
Close an event device.
The device cannot be restarted! This is a one-way door, bestie, it's giving permanent 💀
Parameters
dev_id— event device identifier 🆔
Returns
0on successfully closing device ✅<0on failure to close device:-EINVAL— invalid device id 🙈-ENOTSUP— operation not supported for this device 😭-EAGAIN— device is busy, give it a sec 🫶
struct __rte_aligned (16)
Event vector structure. Let's break it all the way down, field by field 🧚
- < Number of elements valid in this event vector 🔢
- < Offset into the vector array where valid elements start from 📍
- < Reserved for future use 🔒
- < Indicates that the below union attributes have valid information ✅
- < Ethernet device port id 🌐
- < Ethernet device queue id 📬
- < Union to hold common attributes of the vector array 🎀
- < Implementation specific opaque value. An implementation may use this field to hold an implementation specific value to share between dequeue and enqueue operation. The application should not modify this field. 🚫👀
- < Start of the vector array union. Depending upon the event type the vector array can be an array of mbufs or pointers or opaque u64 values 🌈
Definition at line 1441 of file rte_eventdev.h 📄
int rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint16_t eth_port_id, uint32_t * caps)
Retrieve the event device's ethdev Rx adapter capabilities for the specified ethernet port 🦋
Parameters
dev_id— the identifier of the device 🆔eth_port_id— the identifier of the ethernet device 🌐caps— a pointer to memory filled with Rx event adapter capabilities ✨
Returns
0— success, driver provides Rx event adapter capabilities for the ethernet device 💖<0— error code returned by the driver function 😭
int rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t * caps)
Retrieve the event device's timer adapter capabilities ⏰
Parameters
dev_id— the identifier of the device 🆔caps— a pointer to memory to be filled with event timer adapter capabilities ✨
Returns
0— success, driver provided event timer adapter capabilities 💖<0— error code returned by the driver function 😭
int rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id, uint32_t * caps)
Retrieve the event device's crypto adapter capabilities for the specified cryptodev device 🔐
Parameters
dev_id— the identifier of the device 🆔cdev_id— the identifier of the cryptodev device 🔑caps— a pointer to memory filled with event adapter capabilities. It is expected to be pre-allocated & initialized by the caller ⚠️
Returns
0— success, driver provides event adapter capabilities for the cryptodev device 💖<0— error code returned by the driver function 😭
__rte_experimental int rte_event_dma_adapter_caps_get(uint8_t dev_id, uint8_t dmadev_id, uint32_t * caps)
Retrieve the event device's DMA adapter capabilities for the specified dmadev device 🚚
Heads up: this one is marked __rte_experimental, so it's still in its experimental era 🧪
Parameters
dev_id— the identifier of the device 🆔dmadev_id— the identifier of the dmadev device 🚚caps— a pointer to memory filled with event adapter capabilities. It is expected to be pre-allocated & initialized by the caller ⚠️
Returns
0— success, driver provides event adapter capabilities for the dmadev device 💖<0— error code returned by the driver function 😭
int rte_event_eth_tx_adapter_caps_get(uint8_t dev_id, uint16_t eth_port_id, uint32_t * caps)
Retrieve the event device's eth Tx adapter capabilities 📤
Parameters
dev_id— the identifier of the device 🆔eth_port_id— the identifier of the ethernet device 🌐caps— a pointer to memory filled with eth Tx adapter capabilities ✨
…and we're still going, don't you dare close the tab 🫶
Returns 💅
0: Success — the driver provides eth Tx adapter capabilities. periodt.<0: Error code returned by the driver function. 😭
✨ rte_event_dequeue_timeout_ticks() ✨
int rte_event_dequeue_timeout_ticks (uint8_t dev_id, uint64_t ns, uint64_t * timeout_ticks)okay so this one is literally just a unit converter bestie — it turns nanoseconds into a timeout_ticks value that you then hand to rte_event_dequeue_burst(). 🎀
But listen 👀: it only works if the device was configured with the RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT flag. That's the vibe check — no flag, no conversion, iykyk.
Parameters 🫶
dev_id— The identifier of the device.ns— Wait time in nanosecond.timeout_ticks— Value for thetimeout_ticksparameter inrte_event_dequeue_burst().
Returns
0on success. slay 💖-ENOTSUPif the device doesn't support timeouts. 🙈-EINVALifdev_idis invalid ortimeout_ticksisNULL. 💀- other values
< 0on failure.
See also
rte_event_dequeue_burst(), RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT, rte_event_dev_configure()
🌸 rte_event_port_link() 🌸
int rte_event_port_link (uint8_t dev_id, uint8_t port_id, const uint8_t queues[], const uint8_t priorities[], uint16_t nb_links)This is the main-character function fr fr — it links multiple source event queues (the ones you pass in queues) to the destination event port picked by its port_id, with the service priorities you supply in priorities, all on the event device designated by its dev_id. 👑
The link establishment shall enable the event port port_id from receiving events from the specified event queue(s) supplied in queues. ✨
An event queue may link to one or more event ports. The number of links that can be established from an event queue to an event port is implementation defined. (so like, driver's choice, not mine 🫠)
Event queue(s) to event port link establishment can be changed at runtime without re-configuring the device — that's so you can support scaling and reduce the latency of critical work by establishing the link with more event ports at runtime. we love a runtime glow-up. 🔥
When the value of rte_event_dev_info::max_profiles_per_port is greater than or equal to one, this function links the event queues to the default profile_id, i.e. profile_id 0, of the event port.
Parameters 🫶
dev_id— The identifier of the device.port_id— Event port identifier to select the destination port to link.queues— Points to an array ofnb_linksevent queues to be linked to the event port.NULLvalue is allowed, in which case this function links all the configured event queuesnb_event_queueswhich you previously supplied torte_event_dev_configure()to the event portport_id.priorities— Points to an array ofnb_linksservice priorities associated with each event queue link to the event port. The priority defines the event port's servicing priority for the event queue, which may be ignored by an implementation. 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 an implementation-supported priority value.NULLvalue is allowed, in which case this function links the event queues withRTE_EVENT_DEV_PRIORITY_NORMALservicing priority.nb_links— The number of links to establish. This parameter is ignored ifqueuesisNULL.
Returns
The number of links actually established. 🎯 The return value can be less than the value of the nb_links parameter when the implementation has a limitation on specific queue-to-port link establishment, or if invalid parameters are specified in queues. If the return value is less than nb_links, the remaining links at the end of link[] are not established, and the caller has to take care of them. 🫡 If the return value is less than nb_links then the implementation shall update the rte_errno accordingly — possible rte_errno values are:
- (
EDQUOT) Quota exceeded (application tried to link the queue configured withRTE_EVENT_QUEUE_CFG_SINGLE_LINKto more than one event port) 🚫 - (
EINVAL) Invalid parameter
🦋 rte_event_port_unlink() 🦋
int rte_event_port_unlink (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint16_t nb_unlinks)the breakup function 💔 — it unlinks multiple source event queues supplied in queues from the destination event port designated by its port_id on the event device designated by its dev_id.
The unlink call issues an async request to disable the event port port_id from receiving events from the specified event queue queue_id. Event queue(s) to event port unlink establishment can be changed at runtime without re-configuring the device. (async queen — it doesn't finish instantly, so don't come for me 😭)
When the value of rte_event_dev_info::max_profiles_per_port is greater than or equal to one, this function unlinks the event queues from the default profile identifier, i.e. profile 0, of the event port.
See also
rte_event_port_unlinks_in_progress() to poll for completed unlinks. 👀
Parameters 🫶
dev_id— The identifier of the device.port_id— Event port identifier to select the destination port to unlink.queues— Points to an array ofnb_unlinksevent queues to be unlinked from the event port.NULLvalue is allowed, in which case this function unlinks all the event queue(s) from the event portport_id.nb_unlinks— The number of unlinks to establish. This parameter is ignored ifqueuesisNULL.
Returns
The number of unlinks successfully requested. The return value can be less than the value of the nb_unlinks parameter when the implementation has a limitation on specific queue-to-port unlink establishment, or if invalid parameters are specified. If the return value is less than nb_unlinks, the remaining queues at the end of queues[] are not unlinked, and the caller has to take care of them. If the return value is less than nb_unlinks then the implementation shall update the rte_errno accordingly — possible rte_errno values are:
- (
EINVAL) Invalid parameter 💀
🧚 __rte_experimental rte_event_port_profile_links_set() 🧚
__rte_experimental int rte_event_port_profile_links_set (uint8_t dev_id, uint8_t port_id, const uint8_t queues[], const uint8_t priorities[], uint16_t nb_links, uint8_t profile_id)heads up bestie — this one's marked __rte_experimental, so it's giving new-and-shiny, not settled-and-stable. 🧪
it links multiple source event queues supplied in queues to the destination event port designated by its port_id, with the associated profile identifier supplied in profile_id, with service priorities supplied in priorities, on the event device designated by its dev_id. iconic behavior honestly. 👑
If profile_id is set to 0 then the links created by the call rte_event_port_link will be overwritten. 💅 (yes, overwritten. gone. no cap.)
Event ports by default use profile_id 0 unless it is changed using the call rte_event_port_profile_switch().
The link establishment shall enable the event port port_id from receiving events from the specified event queue(s) supplied in queues. ✨
An event queue may link to one or more event ports. The number of links that can be established from an event queue to an event port is implementation defined.
Event queue(s) to event port link establishment can be changed at runtime without re-configuring the device to support scaling and to reduce the latency of critical work by establishing the link with more event ports at runtime. 🔥
Parameters 🫶
dev_id— The identifier of the device.port_id— Event port identifier to select the destination port to link.queues— Points to an array ofnb_linksevent queues to be linked to the event port.NULLvalue is allowed, in which case this function links all the configured event queuesnb_event_queueswhich were previously supplied torte_event_dev_configure()to the event portport_id.priorities— Points to an array ofnb_linksservice priorities associated with each event queue link to the event port. The priority defines the event port's servicing priority for the event queue, which may be ignored by an implementation. 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 an implementation-supported priority value.NULLvalue is allowed, in which case this function links the event queues withRTE_EVENT_DEV_PRIORITY_NORMALservicing priority.nb_links— The number of links to establish. This parameter is ignored ifqueuesisNULL.profile_id— The profile identifier associated with the links between event queues and event port. Should be less than the max capability reported byrte_event_dev_info::max_profiles_per_port.
Returns
The number of links actually established. 🎯 The return value can be less than the value of the nb_links parameter when the implementation has a limitation on specific queue-to-port link establishment, or if invalid parameters are specified in queues. If the return value is less than nb_links, the remaining links at the end of link[] are not established, and the caller has to take care of them. If the return value is less than nb_links then the implementation shall update the rte_errno accordingly — possible rte_errno values are:
- (
EDQUOT) Quota exceeded (application tried to link the queue configured withRTE_EVENT_QUEUE_CFG_SINGLE_LINKto more than one event port) 🚫 - (
EINVAL) Invalid parameter
🎀 __rte_experimental rte_event_port_profile_unlink() 🎀
__rte_experimental int rte_event_port_profile_unlink (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint16_t nb_unlinks, uint8_t profile_id)also __rte_experimental, bestie — same energy, still shiny. 🧪
This one unlinks multiple source event queues supplied in queues that belong to the profile designated by profile_id, from the destination event port designated by its port_id, on the event device designated by its dev_id. it's giving targeted unfollowing. 💅
If profile_id is set to 0, i.e. the default profile, then this function will act as rte_event_port_unlink. (same function, different outfit ✨)
The unlink call issues an async request to disable the event port port_id from receiving events from the specified event queue queue_id. Event queue(s) to event port unlink establishment can be changed at runtime without re-configuring the device.
See also
rte_event_port_unlinks_in_progress() to poll for completed unlinks. 👀
Parameters 🫶
dev_id— The identifier of the device.port_id— Event port identifier to select the destination port to unlink.queues— Points to an array ofnb_unlinksevent queues to be unlinked from the event port.NULLvalue is allowed, in which case this function unlinks all the event queue(s) from the event portport_id.nb_unlinks— The number of unlinks to establish. This parameter is ignored ifqueuesisNULL.profile_id— The profile identifier associated with the links between event queues and event port. Should be less than the max capability reported byrte_event_dev_info::max_profiles_per_port.
Returns
The number of unlinks that got successfully requested. Heads up bestie: this can be less than nb_unlinks — the implementation might have limits on how many unlink establishments it can do for a specific queue-to-port, or you might've handed it invalid parameters. If the return value is less than nb_unlinks, the leftover queues sitting at the end of queues[] are not unlinked, and the caller has to deal with those personally. And when the return value is less than nb_unlinks, the implementation shall update rte_errno accordingly — possible rte_errno values are (EINVAL) Invalid parameter 😭
int rte_event_port_unlinks_in_progress (uint8_t dev_id, uint8_t port_id)
Returns the number of unlinks that are in progress ✨
This one gives the app a way to actually detect when the implementation has finished an unlink. It's giving "are we there yet" but make it syscalls 🎀
See also: rte_event_port_unlink() to issue unlink requests.
Parameters
- dev_id — the identifier of the device.
- port_id — event port identifier, selects the port to check for unlinks in progress.
Returns
The number of unlinks that are in progress.
- A return of zero — no outstanding unlink requests, we're clean 💅
- A positive return value — that many unlinks are in progress but not yet complete, lowkey still cooking 🔥
- A negative return value — an error.
-EINVALmeans an invalid parameter got passed fordev_idorport_id💀
int rte_event_port_links_get (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint8_t priorities[])
Retrieve the list of source event queues and its associated service priority linked to the destination event port designated by its port_id on the event device designated by its dev_id. Basically: "what's actually wired into this port, bestie" 🦋
Parameters
- dev_id — the identifier of the device.
- port_id — event port identifier.
- queues — points to an array of queues for output. The caller has to allocate
RTE_EVENT_MAX_QUEUES_PER_DEVbytes to store the event queue(s) linked with event portport_id. - priorities — points to an array of priorities for output. The caller has to allocate
RTE_EVENT_MAX_QUEUES_PER_DEVbytes to store the service priority associated with each event queue linked.
Returns
The number of links established on the event port designated by its port_id.
<0on failure.
__rte_experimental int rte_event_port_profile_links_get (uint8_t dev_id, uint8_t port_id, uint8_t queues[], uint8_t priorities[], uint8_t profile_id)
Retrieve the list of source event queues and its service priority associated to a profile_id and linked to the destination event port designated by its port_id on the event device designated by its dev_id. Same energy as above, but now it's profile-coded ✨ (note the __rte_experimental, so she's still in beta, handle with care 🙈)
Parameters
- dev_id — the identifier of the device.
- port_id — event port identifier.
- queues — points to an array of queues for output. The caller has to allocate
RTE_EVENT_MAX_QUEUES_PER_DEVbytes to store the event queue(s) linked with event portport_id. - priorities — points to an array of priorities for output. The caller has to allocate
RTE_EVENT_MAX_QUEUES_PER_DEVbytes to store the service priority associated with each event queue linked. - profile_id — the profile identifier associated with the links between event queues and event port. Should be less than the max capability reported by
rte_event_dev_info::max_profiles_per_port.
Returns
The number of links established on the event port designated by its port_id.
<0on failure.
int rte_event_dev_service_id_get (uint8_t dev_id, uint32_t * service_id)
Retrieve the service ID of the event dev. Plot twist: if the adapter doesn't use a rte_service function, this function returns -ESRCH 😭
Parameters
- dev_id — the identifier of the device.
- service_id — a pointer to a
uint32_t, to be filled in with the service id.
Returns
0: Success 👑<0: Error code on failure — if the event dev doesn't use arte_servicefunction, this function returns-ESRCH.
int rte_event_dev_dump (uint8_t dev_id, FILE * f)
Dump internal information about dev_id to the FILE* provided in f. It's giving "spill the tea about yourself" 🍓
Parameters
- dev_id — the identifier of the device.
- f — a pointer to a file for output.
Returns
0: on success ✨<0: on failure 💀
int rte_event_dev_xstats_names_get (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id, struct rte_event_dev_xstats_name * xstats_names, uint64_t * ids, unsigned int size)
Retrieve the names of extended statistics of an event device. Stats girlies rise 🌸
Parameters
- dev_id — the identifier of the event device.
- mode — the mode of statistics to retrieve. Choices include the device statistics, port statistics or queue statistics.
- queue_port_id — used to specify the port or queue number in queue or port mode, and is ignored in device mode.
- xstats_names — block of memory to insert names into. Must be at least
sizein capacity. If set toNULL, the function returns required capacity. - ids — block of memory to insert ids into. Must be at least
sizein capacity. If set toNULL, the function returns required capacity. The id values returned can be passed torte_event_dev_xstats_getto select statistics. - size — capacity of
xstats_names(number of names).
Returns
- positive value lower or equal to
size: success 🎉 The return value is the number of entries filled in the stats table. - positive value higher than
size: error — the given statistics table is too small. The return value corresponds to the size that should be given to succeed. The entries in the table are not valid and shall not be used by the caller 🙈 - negative value on error:
-ENODEVfor invaliddev_id,-EINVALfor invalidmode, queue port or id parameters,-ENOTSUPif the device doesn't support this function.
int rte_event_dev_xstats_get (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id, const uint64_t ids[], uint64_t values[], unsigned int n)
Retrieve extended statistics of an event device. The actual numbers this time, not just the names 💅
Parameters
- dev_id — the identifier of the device.
- mode — the mode of statistics to retrieve. Choices include the device statistics, port statistics or queue statistics.
- queue_port_id — used to specify the port or queue number in queue or port mode, and is ignored in device mode.
- ids — the id numbers of the stats to get. The ids can be got from the stat position in the stat list from
rte_event_dev_get_xstats_names(), or by usingrte_event_dev_xstats_by_name_get(). - values — the values for each stats request by ID.
- n — the number of stats requested.
Returns
- positive value: number of stat entries filled into the
valuesarray ✨ - negative value on error:
-ENODEVfor invaliddev_id,-EINVALfor invalidmode, queue port or id parameters,-ENOTSUPif the device doesn't support this function 💀
uint64_t rte_event_dev_xstats_by_name_get (uint8_t dev_id, const char * name, uint64_t * id)
Retrieve the value of a single stat by requesting it by name. Name-drop the stat, get the stat 🎀
Parameters
- dev_id — the identifier of the device.
- name — the stat name to retrieve.
- id — if non-
NULL, the numerical id of the stat will be returned, so that further requests for the stat can be got usingrte_event_dev_xstats_get, which will be faster as it doesn't need to scan a list of names for the stat. If the stat cannot be found, theidreturned will be(unsigned)-1. Little cursed but okay 😭
Returns
- positive value or zero: the stat value 👑
- negative value:
-EINVALif stat not found,-ENOTSUPif not supported.
int rte_event_dev_xstats_reset (uint8_t dev_id, enum rte_event_dev_xstats_mode mode, int16_t queue_port_id, const uint64_t ids[], uint32_t nb_ids)
Reset the values of the xstats of the selected component in the device. Fresh start, clean slate, new semester energy 🌈
Parameters
- dev_id — the identifier of the device.
- mode — the mode of the statistics to reset. Choose from device, queue or port.
- queue_port_id — the queue or port to reset.
0and positive values select ports and queues, while-1indicates all ports or queues. - ids — selects specific statistics to be reset. When
NULL, all statistics selected bymodewill be reset. If non-NULL, must point to array of at leastnb_idssize. - nb_ids — the number of ids available from the
idsarray. Ignored whenidsisNULL.
Returns
- zero: successfully reset the statistics to zero ✨
- negative value:
-EINVALinvalid parameters,-ENOTSUPif not supported.
int rte_event_dev_selftest (uint8_t dev_id)
Trigger the eventdev self test. It's giving "device, look in the mirror and tell me what you see" 🪞
Parameters
- dev_id — the identifier of the device.
Returns
0: Selftest successful 🎉-ENOTSUPif the device doesn't support selftest- other values
< 0on failure 💀
struct rte_mempool* rte_event_vector_pool_create (const char * name, unsigned int n, unsigned int cache_size, uint16_t nb_elem, int socket_id)
Get the memory required per event vector based on the number of elements per vector. This should be used to create the mempool that holds the event vectors — so like, use this to build the pool, don't roll your own 🧚
Parameters
- name — the name of the vector pool.
- n — the number of elements in the mbuf pool.
- cache_size — size of the per-core object cache. See
rte_mempool_create()for details. - nb_elem — the number of elements that a single event vector should be able to hold.
- socket_id — the socket identifier where the memory should be allocated. The value can be
SOCKET_ID_ANYif there is no NUMA constraint for the reserved zone.
Returns
The pointer to the newly allocated mempool, on success. NULL on error with rte_errno set appropriately. Possible rte_errno values include:
E_RTE_NO_CONFIG— function could not get pointer torte_configstructureE_RTE_SECONDARY— function was called from a secondary process instanceEINVAL— cache size provided is too large, orpriv_sizeis not alignedENOSPC— the maximum number of memzones has already been allocatedEEXIST— a memzone with the same name already existsENOMEM— no appropriate memory area found in which to create memzoneENAMETOOLONG— mempool name requested is too long
So many ways to fail, but like... each one is documented, so at least you know why 😭💖
static uint16_t rte_event_enqueue_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events) [inline], [static]
Enqueue a burst of events objects or an event object supplied in rte_event structure on an event device designated by its dev_id through the event port specified by port_id. Each event object specifies the event queue on which it will be enqueued. Bulk-sending events, main character energy only 🔥👑
The nb_events parameter is literally just how many event objects you're enqueuing, bestie, and they're all sitting in the ev array of rte_event structures. 💅
🚨 ok real talk:RTE_EVENT_OP_FORWARDandRTE_EVENT_OP_RELEASEoperations must only be enqueued to the same port that their associated events were dequeued from. That's not a suggestion, that's the rule. No cap.
rte_event_enqueue_burst() hands back how many event objects it actually enqueued. If the return value equals nb_events, you ate — everything got enqueued, slay. 👑
Parameters
dev_id— the identifier of the device.port_id— the identifier of the event port.ev— points to an array ofnb_eventsobjects of typerte_eventstructure which contain the event object enqueue operations to be processed.nb_events— the number of event objects to enqueue, typically number ofrte_event_port_attr_get(...RTE_EVENT_PORT_ATTR_ENQ_DEPTH...)available for this port.
Returns
The number of event objects <pink>actually</pink> enqueued on the event device. Fr fr, the return value can be less than nb_events when the event device's queue is full or if invalid parameters are specified in a rte_event. And if it comes back less than nb_events, the remaining events at the end of ev[] are not consumed and the caller has to take care of them 😭 — plus rte_errno gets set accordingly. Possible errno values include:
EINVAL— the port ID is invalid, device ID is invalid, an event's queue ID is invalid, or an event's sched type doesn't match the capabilities of the destination queue.ENOSPC— the event port was backpressured and unable to enqueue one or more events. This error code is only applicable to closed systems.
See also
rte_event_port_attr_get(), RTE_EVENT_PORT_ATTR_ENQ_DEPTH
Definition at line 2662 of file rte_eventdev.h.
static uint16_t rte_event_enqueue_new_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events) [inline], [static]
static uint16_t rte_event_enqueue_new_burst(uint8_t dev_id, uint8_t port_id,
const struct rte_event ev[],
uint16_t nb_events);Enqueue a burst of event objects of operation type RTE_EVENT_OP_NEW on an event device designated by its dev_id, through the event port specified by port_id. ✨
It gives you the same functionality as rte_event_enqueue_burst(), except that the application can use this API when all objects in the burst contain the enqueue operation of the type RTE_EVENT_OP_NEW. This specialized function can provide the additional hint to the PMD and optimize if possible — basically you're telling the driver "bestie I promise they're all NEW", and it might go faster because of it. 🦋
💀 Careful though: therte_event_enqueue_new_burst()result is undefined if the enqueue burst has an event object of operation type!= RTE_EVENT_OP_NEW. That's undefined behavior, not a vibe. Don't do it.
Parameters
dev_id— the identifier of the device.port_id— the identifier of the event port.ev— points to an array ofnb_eventsobjects of typerte_eventstructure which contain the event object enqueue operations to be processed.nb_events— the number of event objects to enqueue, typically number ofrte_event_port_attr_get(...RTE_EVENT_PORT_ATTR_ENQ_DEPTH...)available for this port.
Returns
The number of event objects actually enqueued on the event device. The return value can be less than the value of the nb_events parameter when the event device's queue is full or if invalid parameters are specified in a rte_event. If the return value is less than nb_events, the remaining events at the end of ev[] are not consumed and the caller has to take care of them, and rte_errno is set accordingly. Possible errno values include:
EINVAL— the port ID is invalid, device ID is invalid, an event's queue ID is invalid, or an event's sched type doesn't match the capabilities of the destination queue.ENOSPC— the event port was backpressured and unable to enqueue one or more events. This error code is only applicable to closed systems.
See also
rte_event_port_attr_get(), RTE_EVENT_PORT_ATTR_ENQ_DEPTH
rte_event_enqueue_burst()
Definition at line 2714 of file rte_eventdev.h.
static uint16_t rte_event_enqueue_forward_burst (uint8_t dev_id, uint8_t port_id, const struct rte_event ev[], uint16_t nb_events) [inline], [static]
static uint16_t rte_event_enqueue_forward_burst(uint8_t dev_id, uint8_t port_id,
const struct rte_event ev[],
uint16_t nb_events);Enqueue a burst of event objects of operation type RTE_EVENT_OP_FORWARD on an event device designated by its dev_id, through the event port specified by port_id. 🎀
Provides the same functionality as rte_event_enqueue_burst(), except that the application can use this API when all objects in the burst contain the enqueue operation of the type RTE_EVENT_OP_FORWARD. This specialized function can provide the additional hint to the PMD and optimize if possible — forward-only energy, iykyk. 🔥
⚠️ Therte_event_enqueue_new_burst()result is undefined if the enqueue burst has an event object of operation type!= RTE_EVENT_OP_FORWARD. (yes, the docs literally namerte_event_enqueue_new_burst()right here in the forward-burst section — we don't make the rules, we just report them 💀) Either way: undefined behavior is undefined. Don't.
Parameters
dev_id— the identifier of the device.port_id— the identifier of the event port.ev— points to an array ofnb_eventsobjects of typerte_eventstructure which contain the event object enqueue operations to be processed.nb_events— the number of event objects to enqueue, typically number ofrte_event_port_attr_get(...RTE_EVENT_PORT_ATTR_ENQ_DEPTH...)available for this port.
Returns
The number of event objects actually enqueued on the event device. The return value can be less than the value of the nb_events parameter when the event device's queue is full or if invalid parameters are specified in a rte_event. If the return value is less than nb_events, the remaining events at the end of ev[] are not consumed and the caller has to take care of them, and rte_errno is set accordingly. Possible errno values include:
EINVAL— the port ID is invalid, device ID is invalid, an event's queue ID is invalid, or an event's sched type doesn't match the capabilities of the destination queue.ENOSPC— the event port was backpressured and unable to enqueue one or more events. This error code is only applicable to closed systems.
See also
rte_event_port_attr_get(), RTE_EVENT_PORT_ATTR_ENQ_DEPTH
rte_event_enqueue_burst()
Definition at line 2766 of file rte_eventdev.h.
static uint16_t rte_event_dequeue_burst (uint8_t dev_id, uint8_t port_id, struct rte_event ev[], uint16_t nb_events, uint64_t timeout_ticks) [inline], [static]
static uint16_t rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id,
struct rte_event ev[],
uint16_t nb_events,
uint64_t timeout_ticks);Dequeue a burst of event objects — or like, one event object, no pressure — from the event port designated by port_id, on an event device designated by its dev_id. 🌸
rte_event_dequeue_burst() does not dictate the specifics of the scheduling algorithm, because each eventdev driver may have different criteria to schedule an event. But from an application perspective, the scheduler may generally use the following scheme to dispatch an event to the port:
- Selection of event queue based on:
- The list of event queues linked to the event port.
- If the device has
RTE_EVENT_DEV_CAP_QUEUE_QOScapability then event queue selection from list is based on event queue priority relative to other event queue supplied as priority inrte_event_queue_setup(). - If the device has
RTE_EVENT_DEV_CAP_EVENT_QOScapability then event queue selection from the list is based on event priority supplied as priority inrte_event_enqueue_burst().
- Selection of event:
- The number of flows available in selected event queue.
- Schedule type method associated with the event.
The nb_events parameter is the maximum number of event objects to dequeue, which get returned in the ev array of rte_event structure. 🌈
rte_event_dequeue_burst() returns the number of event objects it actually dequeued. Return value equal to nb_events means all event objects have been dequeued — iconique. 👑
The number of events dequeued is the number of scheduler contexts held by this port. Those contexts are automatically released in the next rte_event_dequeue_burst() invocation if the port supports implicit releases, or invoking rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE operation can be used to release the contexts early.
🚨 again for the people in the back: event operationsRTE_EVENT_OP_FORWARDandRTE_EVENT_OP_RELEASEmust only be enqueued to the same port that their associated events were dequeued from.
Parameters
dev_id— the identifier of the device.port_id— the identifier of the event port.ev— points to an array ofnb_eventsobjects of typerte_eventstructure for output, to be populated with the dequeued event objects.nb_events— the maximum number of event objects to dequeue, typically number ofrte_event_port_dequeue_depth()available for this port.timeout_ticks—0→ no-wait, returns immediately if there is no event. 🙈>0→ wait for the event. If the device is configured withRTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUTthen this function will wait until at least one event is available ortimeout_tickstime. If the device is not configured withRTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUTthen this function will wait until the event is available ordequeue_timeout_nsns, which was previously supplied torte_event_dev_configure().
Returns
The number of event objects actually dequeued from the port. The return value can be less than the value of the nb_events parameter when the event port's queue is not full.
See also
rte_event_port_dequeue_depth()
Definition at line 2843 of file rte_eventdev.h.
static int rte_event_maintain (uint8_t dev_id, uint8_t port_id, int op) [inline], [static]
static int rte_event_maintain(uint8_t dev_id, uint8_t port_id, int op);Maintain an event device. 🧚
This function is only relevant for event devices which do not have the RTE_EVENT_DEV_CAP_MAINTENANCE_FREE flag set. Such devices require an application thread using a particular port to periodically call rte_event_maintain() on that port during periods when it is neither attempting to enqueue events to nor dequeue events from the port. rte_event_maintain() is a low-overhead function and should be called at a high rate (e.g., in the application's poll loop). ⭐
💀 No port may be left unmaintained. That's the whole vibe check. If you abandon a port, you're on your own.
At the application thread's convenience, rte_event_maintain() may (but is not required to) be called even during periods when enqueue or dequeue functions are being called, at the cost of a slight increase in overhead. Your call, king. 🫶
rte_event_maintain() may be called on event devices which have set RTE_EVENT_DEV_CAP_MAINTENANCE_FREE, in which case it is a no-operation — literally nothing happens, it's giving "I'm here but I'm not doing anything" energy. 💅
Parameters
dev_id— the identifier of the device.port_id— the identifier of the event port.op—0, orRTE_EVENT_DEV_MAINT_OP_FLUSH.
Returns
0on success. ✨-EINVALifdev_id,port_id, oropis invalid.
See also
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE
Definition at line 2911 of file rte_eventdev.h.
💅 rte_event_port_profile_switch
static uint8_t rte_event_port_profile_switch (uint8_t dev_id, uint8_t
port_id, uint8_t profile_id) [inline], [static]Okay so this one is literally the profile switcher — it changes the active profile on an event port 🔥
When you've got multiple link profiles set up on an event port (you did that with rte_event_port_profile_links_set, bestie, remember?), this is the function that flips which one is live.
And then — the important part — on the subsequent rte_event_dequeue_burst call, only the event queues that were associated with the newly active profile get to participate in scheduling. That's it. That's the vibe check. ✨
Parameters
dev_id— the identifier of the deviceport_id— the identifier of the event portprofile_id— the identifier of the profile
Returns
0on success 🎀-EINVALifdev_id,port_id, orprofile_idis invalid 💀
Definition at line 2959 of file rte_eventdev.h.
🧚 rte_event_port_preschedule_modify
static __rte_experimental int rte_event_port_preschedule_modify (uint8_t
dev_id, uint8_t port_id, enum rte_event_dev_preschedule_type type)
[inline], [static]This lil icon changes the current pre-schedule type configured on an event port — and yes, you can set the pre-schedule type to none to straight-up disable pre-scheduling 🙈
It takes effect on the subsequent rte_event_dequeue_burst call. And heads up: the event device should support the RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE capability, bestie, don't forget that part.
Real talk: to avoid fastpath capability checks, if an event device does not supportRTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE, then this function will return-ENOTSUP. No cap. 🧢
Parameters
dev_id— the identifier of the deviceport_id— the identifier of the event porttype— the preschedule type to use on the event port
Returns
0on success ⭐-EINVALifdev_id,port_id, ortypeis invalid-ENOTSUPif the device does not support per port preschedule capability 😭
Definition at line 3008 of file rte_eventdev.h.
💜 rte_event_port_preschedule
static __rte_experimental void rte_event_port_preschedule (uint8_t dev_id,
uint8_t port_id, enum rte_event_dev_preschedule_type type) [inline],
[static]This is the hint girlie 🫶 — it hints to the event device to pre-schedule events to the event port. That's it, that's the whole job.
Important caveats, and I'm saying them with my whole chest:
- The call does not guarantee that the events will be pre-scheduled 💀
- The call does not release the flow context currently held by the event port
- The event device should support the
RTE_EVENT_DEV_CAP_PRESCHEDULE_EXPLICITcapability
Also: when pre-scheduling is enabled at an event device / port level, or if the capability is not supported, then the hint is simply ignored. Bye. 👋
And then: subsequent calls to rte_event_dequeue_burst() will dequeue the pre-schedule events, but the pre-schedule operation is not issued again. Note that. 📝
Parameters
dev_id— the identifier of the deviceport_id— the identifier of the event porttype— the pre-schedule type to use on the event port
Definition at line 3052 of file rte_eventdev.h.
🌈 Author
Generated automatically by Doxygen for DPDK from the source code. So like, nobody hand-wrote this for you — a robot did it, and honestly? It ate. 👑
And that's a wrap on rte_eventdev.h(3), bestie!! 🎀✨ You made it to the very end of the whole page — I'm so proud of you fr fr 🫶
This iconic lil doc is Version 25.11.0, dated Fri Jan 30 2026 🌸 Go forth, schedule those events, and remember: only the queues in your active profile get to participate. Periodt. 💅
📦 where this page comes from
- centos-stream 9: dpdk-devel 2:25.11-1.el9 · BSD and LGPLv2 and GPLv2
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms