hwrm_req_alloc_flags(9)

📦 version 7.3.1, in nixpkgs unstable

💖 hwrm_req_alloc_flags — the kernel API manual, but make it make sense 💖

okay so bestie, this is a page from the Kernel API Manual, and it's about hwrm_req_alloc_flags. it's literally the function that sets your GFP allocation flags for slices. that's the whole vibe. ngl it's a little niche but we're gonna slay it anyway 🫶

✨ SYNOPSIS ✨

void hwrm_req_alloc_flags (struct bnxt *bp , void *req , gfp_t gfp );

like, that's it. three args, no return value, no drama. 💅

🎀 ARGUMENTS 🎀

  • bp — the driver context. that's your main character right there 👑
  • req — the request for which calls to hwrm_req_dma_slice will have altered allocation flags. so like, you're telling this specific request "hey bestie, your slice allocations are gonna behave different from now on" 🦋
  • gfp — a bitmask of GFP flags. these flags get passed to dma_alloc_coherent whenever it's used to allocate backing memory for slices. ⚠️ important caveat though: calls to hwrm_req_dma_slice will not always result in new allocations — but memory suballocated from the request buffer is already __GFP_ZERO, so you're covered there anyway. no cap. 💀

🌸 DESCRIPTION 🌸

so what does it actually do? it sets the GFP allocation flags associated with the request for subsequent calls to hwrm_req_dma_slice. that's the entire plot. 📖

and like, why do you care? because this is genuinely useful for specifying __GFP_ZERO for slice allocations. yes queen, zeroed memory on demand ✨

lowkey just remember: the flags live on the request, not on the individual slice call. set once, vibe forever. 🧚

💜 SEE ALSO 💜

like the whole hwrm_req friend group, fr fr. go say hi to all of them 🌈

and that's the page!! mwah 💋 this came from ./drivers/net/ethernet/broadco..., dated October 2026, and yes the header and footer both said hwrm_req_alloc_flags(9) because it's that iconic. periodt. 🔥🎀

📦 where this page comes from