tso_dma_map_count(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… tso_dma_map_count(9) β€” like, the kernel API manual, but make it make sense πŸŽ€

okay so bestie, welcome to the Kernel API Manual page for tso_dma_map_count β€” she lives in the 9 section, and honestly? she's a tiny little function with one job and she does it slayfully. let's get into it ✨


🌸 NAME 🌸

tso_dma_map_count β€” counts the descriptors for a payload range. that's it. that's the whole vibe check. πŸ’…


✨ SYNOPSIS ✨

unsigned int tso_dma_map_count (struct tso_dma_map *map , unsigned int
len );

like yes, she returns an unsigned int, and yes, she takes two args. no cap. 🫢


🧚 ARGUMENTS 🧚

  • map β€” the payload map. your main character struct, the one holding all the state. 🌈
  • len β€” number of payload bytes in this segment. just how many bytes you're asking about, bestie. πŸ“

πŸ’– DESCRIPTION πŸ’–

so what she does is: she counts how many contiguous DMA region chunks the next len bytes are gonna span β€” and the way that she does it without advancing the iterator?? iconic. she looks, she counts, she leaves everything exactly where she found it. no side effects, no drama, no moving the pointer. πŸ™ˆ

here's the tea on how the count goes down:

  • on the IOVA path, the answer is always 1</>, because it's contiguous. one chunk, one descriptor, done. periodt. ✨
  • on the fallback path, she uses the region sizes from the current position to figure it out. so the number genuinely depends on where you're sitting and how big the regions are from there. πŸ”₯

⭐ RETURN ⭐

she returns the number of descriptors needed for len bytes of payload. that's your answer, bestie, go spend it wisely. πŸ’œ


πŸ‘‘ SEE ALSO πŸ‘‘


okay that's the whole page, you ate that. and for the cute sign-off: this little gem comes from ./net/core, dated October 2026 β€” and it's the tso_dma_map_count(9) page, mwah πŸ’‹πŸŒ·

πŸ“¦ where this page comes from