XDP RX-QUEUE INFORMATION(9)

💅 XDP RX-queue information 💅

okay bestie, so this page lives in the Kernel API Manual (yes, the whole thing is a Kernel API Manual situation, we love that for us) and it's all about one very specific little struct. let's get into it 🫶

The XDP RX-queue info (xdp_rxq_info) is associated with the driver level RX-ring queues. it's literally information that is specific to how the driver has configured a given RX-ring queue. like, that specific queue. no cap.

Each xdp_buff frame received in the driver carries a (pointer) reference to this xdp_rxq_info structure. ✨ so that's how the XDP data-path gets its read-access to the RX-info — for both kernel and bpf-side (limited subset, iykyk, bpf only gets a lil taste 🙈).

🚨 okay so for now, direct access is only safe while running in NAPI/softirq context. contents are read-mostly and must not be updated during driver NAPI/softirq poll. like, do not. 💀

The driver usage API is a register and unregister API. that's the whole vibe.

🦋 the tea on the struct 🌸

The struct is not directly tied to the XDP prog. a new XDP prog can be attached as long as it doesn't change the underlying RX-ring. iconic, flexible, main character energy. 👑

But — if the RX-ring does change significantly, the NIC driver naturally needs to stop the RX-ring before purging and reallocating memory. and in that process the driver MUST call unregister. 🫵 (and yes, that also applies for driver shutdown and unload, don't skip it bestie 😭). the register API is also mandatory during RX-ring setup. mandatory. periodt. 💅

✨ SEE ALSO ✨

• Kernel file ./include/net/xdp.h
• __xdp_buff_add_frag(9)
• xdp_buff_add_frag(9)
• xdp_rxq_info_attach_mem_model(9)
• xdp_rxq_info_detach_mem_model(9)

🎀 that's the whole page fr fr — brought to you by ./include/net, stamped October 2026. go forth and register/unregister responsibly, bestie 💖🌈⭐