STRUCT DPNI_QUEUE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 struct dpni_queue(9) β€” the kernel API glow-up πŸŽ€

okay so bestie, buckle up: this is struct dpni_queue(9) from the Kernel API Manual, and it's literally the blueprint for a queue. That's the whole NAME section. Short, sweet, iconic. πŸ’…


✨ SYNOPSIS ✨

here's the shape of it, verbatim, no cap:

struct dpni_queue {
    struct {
      u16 id;
      enum dpni_dest type;
      char hold_active;
      u8 priority;
    } destination;
    u64 user_context;
    struct {
      u64 value;
      char stash_control;
    } flc;
 };

like. look at her. nested structs, nested vibes. πŸ¦‹


πŸ‘‘ Members πŸ‘‘

destination

the destination structure πŸ’– (yes that's the entire description, she's mysterious)

destination.id

the ID of the destination. only relevant if DEST_TYPE is > 0, okay?? it identifies either a DPIO or a DPCON object. and ngl β€” not relevant for Tx queues. periodt.

destination.type

lowkey the main character of this struct. may be one of the following:

  • 0 β€” no destination. the queue can be manually queried, but it will not push traffic or notifications to a DPIO.
  • 1 β€” the destination is a DPIO. when traffic becomes available in the queue, a FQDAN (FQ data available notification) gets generated to the selected DPIO. πŸ’«
  • 2 β€” the destination is a DPCON. the queue is associated with a DPCON object for the purpose of scheduling between multiple queues. the DPCON may be independently configured to generate notifications.

and again, bestie: not relevant for Tx queues. πŸ™ˆ

destination.hold_active

"hold active" β€” it maintains a queue scheduled for longer in a DPIO during dequeue, which reduces the spread of traffic. 🧚 only relevant if the queues are not affined to a single DPIO, so keep that in mind.

user_context

user data 🫢 β€” it gets presented to the user along with any frames from this queue. and yeah: not relevant for Tx queues. we been knew.

flc

the FD FLow Context structure ✨ (yes, "FLow" with a capital L, that's how the manpage spells it, don't come for me)

flc.value

the default FLC value for traffic dequeued from this queue. bestie please check the description of the FD structure for more info, fr fr. also β€” heads up β€” FLC values set using dpni_add_fs_entry, if any, take precedence over values per queue. so those win. 😭

flc.stash_control

a boolean, indicating whether the 6 lowest significant bits are used for stash control. πŸ”₯ if it's set, the 6 least significant bits in value are interpreted like this:

  • bits 0-1 β€” indicates the number of 64 byte units of context that are stashed. in this case the FLC value is interpreted as a memory address, excluding the 6 LS bits.
  • bits 2-3 β€” indicates the number of 64 byte units of frame annotation to be stashed. the annotation is placed at FD[ADDR].
  • bits 4-5 β€” indicates the number of 64 byte units of frame data to be stashed. the frame data is placed at FD[ADDR] + FD[OFFSET]. for more details check the Frame Descriptor section in the hardware documentation. πŸ“š
lowkey a warning but also just a heads up: that's the hardware doc's job to explain, not mine. go read it. 🫑

🌈 SEE ALSO 🌈

the kernel file itself lives at ./drivers/net/ethernet/freescale/dpaa2/dpni.h β€” go say hi to her πŸ‘‹

and now the iconique extended universe, every single one, no skips:


and that's the whole page, bestie. πŸ“ she comes from ./drivers/net/ethernet/freesca… (yes the path is literally truncated in the footer, we don't gatekeep, we just vibe) and she's dated October 2026 β€” future queen behavior honestly πŸ’œβœ¨ mwah, go write some queues πŸŽ€

πŸ“¦ where this page comes from