SDMA PSM VERBS API(9)

💅 sdma PSM/verbs API 💅

okay so this is a page from the Kernel API Manual (section 9, bestie, we're in kernel-land now ✨) and it's all about the sdma API — which is literally designed to be used by both PSM and verbs to feed packets to the SDMA ring. two besties, one ring, we love to see it 🫶

---

🌸 the whole usage vibe, step by step 🌸

ok so here's how you actually use this thing:

• First up: embed a struct iowait in the QP or the PQ. that iowait needs to be initialized with a call to iowait_init. no skipping, bestie 💅
• Then you (the user of the API) gotta create an allocation method for your version of the txreq. slabs? pre-allocated lists? dma pools? all valid, pick your fighter ✨
• Once your overload of the sdma_txreq has been allocated, the sdma_txreq member must be initialized with sdma_txinit or sdma_txinit_ahg.
• and listen — the txreq must be declared with the sdma_txreq first. that's the rule, periodt 👑

---

🦋 adding memory locations 🦋

once the tx request is initialized, you manipulate it with calls to sdma_txadd_daddr, sdma_txadd_page, or sdma_txadd_kvaddr for each disjoint memory location.

it is your responsibility (yes, yours, main character 🎀) to understand the packet boundaries and page boundaries so you do the appropriate number of sdma_txadd_* calls.

also you gotta be prepared to deal with failures from these routines — they can fail from either memory allocation or dma_mapping failures. no cap, plan for it 😭

The mapping specifics for each memory location get recorded in the tx. Memory locations added with sdma_txadd_page and sdma_txadd_kvaddr are automatically mapped when they're added to the tx, and then nmapped (that's literally what the page says, i'm not fixing it 🙈) as part of the progress processing in the SDMA interrupt handling.

sdma_txadd_daddr is the one you use to add a dma_addr_t memory to the tx. a classic use case? a pre-allocated set of headers allocated via dma_pool_alloc or dma_alloc_coherent. but heads up: for these memory locations, it's on you to handle that unmapping. (usually that'd be at an unload or job termination.) 💀

---

🧚 sending it 🌈

The routine sdma_send_txreq is what you use to submit a tx to the ring — after you've done the appropriate number of sdma_txadd_* calls.

Wanna send a whole burst of sdma_txreqs? sdma_send_txlist is right there, girlie — use it to submit a list of packets. slay 🔥

---

👑 the freebies 👑

The user is free to use the link overhead in the struct sdma_txreq — as long as the tx isn't in flight. that's the whole condition, iykyk ⭐

And the extreme degenerate case where the number of descriptors exceeds the ring size? automatically handled as memory locations are added. An overflow of the descriptor array that's part of the sdma_txreq? also automatically handled. iconic behaviour honestly, it just deals with it 💖

---

✨ SEE ALSO ✨

• Kernel file ./drivers/infiniband/hw/hfi1/sdma.h
• sdma exported routines(9)
• Infrastructure calls(9)
• struct sdma_engine(9)
• sdma_empty(9)
• sdma_running(9)
• sdma_txinit_ahg(9)
• sdma_txinit(9)
• sdma_txadd_page(9)
• sdma_txadd_daddr(9)
• sdma_txadd_kvaddr(9)
• sdma_progress(9)
• struct sdma_map_elem(9)
• sdma_engine_progress_schedule(9)

---

okay that's the whole page, bestie 🎀 this lives down in ./drivers/infiniband/hw/hfi1, and the footer is dated October 2026 — so yeah, future vibes only 🌸 bye, go map some pages responsibly 💜