STRUCT IDPF_Q_VEC_RSRC(9)

๐Ÿ“ฆ version 7.3.1, in nixpkgs unstable

๐Ÿ’– struct idpf_q_vec_rsrc(9) ๐Ÿ’–

okay so you're reading the Kernel API Manual (that's the manual name bestie, we're in kernel-doc land now) and this page is literally all about struct idpf_q_vec_rsrc โ€” the handle for queue and vector resources. it's giving "one struct to hold every queue-and-vector thing you'll ever need" and honestly? iconic. ๐ŸŽ€


โœจ NAME โœจ

struct idpf_q_vec_rsrc โ€” handle for queue and vector resources ๐Ÿฆ‹


โœจ SYNOPSIS โœจ

struct idpf_q_vec_rsrc {
    struct device           *dev;
    struct idpf_q_vector    *q_vectors;
    u16 *q_vector_idxs;
    u16 num_q_vectors;
    u16 noirq_v_idx;
    u32 noirq_dyn_ctl_ena;
    void __iomem            *noirq_dyn_ctl;
    struct idpf_txq_group   *txq_grps;
    u32 txq_desc_count;
    u32 complq_desc_count;
    u32 txq_model;
    u16 num_txq;
    u16 num_complq;
    u16 num_txq_grp;
    u16 xdp_txq_offset;
    u16 num_rxq_grp;
    u32 rxq_model;
    struct idpf_rxq_group   *rxq_grps;
    u16 num_rxq;
    u16 num_bufq;
    u32 rxq_desc_count;
    u32 bufq_desc_count[IDPF_MAX_BUFQS_PER_RXQ_GRP];
    u8 num_bufqs_per_qgrp;
    bool base_rxd;
 };

look at that layout. absolutely ate. no cap, every single field is right there and we're gonna go through all of them together ๐Ÿ’…


๐ŸŒธ Members ๐ŸŒธ

๐Ÿงš The device + vector side

  • dev โ€” device pointer for DMA mapping. like, the actual thing you're mapping DMA against ๐Ÿซถ
  • q_vectors โ€” array of queue vectors. the whole squad of them.
  • q_vector_idxs โ€” starting index of queue vectors.
  • num_q_vectors โ€” number of IRQ vectors allocated. count 'em.
  • noirq_v_idx โ€” ID of the NOIRQ vector.
  • noirq_dyn_ctl_ena โ€” the value to write to the above to enable it. (the above = that register right below, keep reading lol)
  • noirq_dyn_ctl โ€” register to enable/disable the vector for NOIRQ queues ๐Ÿ”ฅ

๐ŸŽ€ The TX side

  • txq_grps โ€” array of TX queue groups.
  • txq_desc_count โ€” TX queue descriptor count.
  • complq_desc_count โ€” completion queue descriptor count.
  • txq_model โ€” split queue or single queue queuing model.
  • num_txq โ€” number of allocated TX queues.
  • num_complq โ€” number of allocated completion queues.
  • num_txq_grp โ€” number of TX queue groups.
  • xdp_txq_offset โ€” index of the first XDPSQ (== number of regular SQs). yes the double equals is literally in the original, we respect it ๐Ÿ’œ

๐Ÿฆ‹ The RX side

  • num_rxq_grp โ€” number of RX queues in a group.
  • rxq_model โ€” splitq queue or single queue queuing model. (their spelling, not mine, keeping it ๐Ÿ’€)
  • rxq_grps โ€” total number of RX groups. Number of groups * number of RX per group will yield total number of RX queues. math slay ๐Ÿงฎโœจ
  • num_rxq โ€” number of allocated RX queues.
  • num_bufq โ€” number of allocated buffer queues.
  • rxq_desc_count โ€” RX queue descriptor count. *MUST* have enough descriptors to complete all buffer descriptors for all buffer queues in the worst case. like, genuinely must. that's an all-caps MUST, do not play with it ๐Ÿ™ˆ
  • bufq_desc_count โ€” buffer queue descriptor count. it's an array sized IDPF_MAX_BUFQS_PER_RXQ_GRP, just saying ๐Ÿ‘€
  • num_bufqs_per_qgrp โ€” buffer queues per RX queue in a given grouping.
  • base_rxd โ€” true if the driver should use base descriptors instead of flex.
fr fr the only scary one here is rxq_desc_count โ€” that MUST is doing a lot of heavy lifting. give it enough descriptors or the worst case will find you. ๐Ÿ˜ญ

๐Ÿ”ฅ SEE ALSO ๐Ÿ”ฅ

Kernel file ./drivers/net/ethernet/intel/idpf/idpf.h โ€” and bestie, the whole friend group is listed, we're going through all of them:

like?? that's a whole group chat of references and every single one of them made the list. obsessed. ๐Ÿ‘‘


and that's the page!! source is ./drivers/net/ethernet/intel/idpf, dated October 2026, and it's living in the Kernel API Manual โ€” mwah, bye bestie, go read your queue descriptors ๐Ÿ’œโœจ๐ŸŽ€

๐Ÿ“ฆ where this page comes from