STRUCT LIBIE_CTLQ_MSG(9)

🎀 struct libie_ctlq_msg(9) 🎀

okay bestie, so this is the kernel API manual page for struct libie_ctlq_msg(9) — yes the section 9 one, and it's literally the control queue message data struct. like, the whole vibe of a control-queue message, all wrapped up in one little C struct. it's giving "backstage pass to the queue" ngl 💅

✨ NAME ✨

struct libie_ctlq_msg — control queue message data 🦋

🌸 SYNOPSIS 🌸

ok so here's the whole thing, and yes you can copy it, go off:

struct libie_ctlq_msg {
    u16 flags;
    u16 opcode;
    u16 data_len;
    union {
      u16 func_id;
      u16 hw_retval;
    };
    u32 chnl_opcode;
    u32 chnl_retval;
    u32 param0;
    u16 sw_cookie;
    u16 virt_flags;
    u64 addr_param;
    union {
      struct kvec             recv_mem;
      struct libie_cp_dma_mem send_mem;
    };
 };

like… she's got unions inside her, she's got u16s and u32s and a u64, she's that girl 💜

---

👑 Members 👑

okay so member by member, let's get into it 🫶

• flags — refer to the 'Flags sub-structure' definitions ✨ (yes, with that exact capitalisation and quotes, iykyk)
• opcode — infrastructure message opcode 🔥
• data_len — size of the payload, i.e. how much stuff is actually in there 💖
• {unnamed_union} — anonymous 😭 that's literally what it says. no name. she's mysterious like that.
  • func_id — queue id for mailbox selection, and it's 0 for the default mailbox (Tx) 📬
  • hw_retval — execution status from the HW (Rx) ⭐
• chnl_opcode — virtchnl message opcode 🌈
• chnl_retval — virtchnl return value 🎀
• param0 — indirect message raw parameter0 (yes, "raw parameter0", no space, that's the name bestie 🙈)
• sw_cookie — used to verify the response of the sent virtchnl message 🍓 like a lil matching key so you know the reply is yours
• virt_flags — virtchnl capability flags 🌸
• addr_param — additional parameters in place of the address, given no buffer 💀 (translation: when there's no buffer, the address slot gets repurposed)
• {unnamed_union} — anonymous, again 💅 (there are two of these, keep both, don't merge them)
  • recv_mem — virtual address and size of the buffer that contains the indirect response 📥
  • send_mem — physical and virtual address of the DMA buffer, used for sending 📤

fr fr, the two anonymous unions are separate things — the top one is func_id/hw_retval (Tx queue id vs Rx hw status), the bottom one is your recv buffer vs your send buffer. don't mix them up, that's the whole point of them being bare/nested like that. 🧚

---

🦋 SEE ALSO 🦋

the whole friend group 🫶:

• Kernel file ./include/linux/net/intel/libie/controlq.h enum
• libie_ctlq_type(9)
• struct libie_ctlq_ctx(9)
• struct libie_ctlq_reg(9)
• struct libie_cp_dma_mem(9)
• struct libie_ctlq_create_info(9)
• struct libie_ctlq_info(9)
• struct libie_ctlq_desc(9)
• struct libie_ctlq_clean_params(9)
• libie_ctlq_release_rx_buf(9)
• enum libie_ctlq_xn_state(9)
• struct libie_ctlq_xn(9)
• struct libie_ctlq_xn_manager(9)
• struct libie_ctlq_xn_send_params(9)
• libie_cp_can_send_onstack(9)
• struct libie_ctlq_xn_recv_params(9)
• struct libie_ctlq_xn_init_params(9)

---

aaaand that's the page 💖 this one lives in ./include/linux/net/intel/libie, dated October 2026, and it's the struct libie_ctlq_msg(9) page — slay, go read the header file, mwah 🎀✨