dsa_lag_unmap(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… dsa_lag_unmap β€” from the Kernel API Manual, section 9, bestie

okay so picture this: you're deep in the kernel, section 9 of the manual, and you need to unmap a LAG ID. that's the whole vibe. dsa_lag_unmap is the function that does the un-mapping, and honestly? she's a team player about it. πŸŽ€


✨ SYNOPSIS ✨

void dsa_lag_unmap (struct dsa_switch_tree *dst , struct dsa_lag *lag );

no return value, no drama β€” it's void, she just does the thing and dips. πŸ¦‹


🌸 ARGUMENTS 🌸

  • dst β€” the tree 🌳 where the mapping is recorded. like, the official record-holder. that's where the paperwork lives.
  • lag β€” the struct dsa_lag that was mapped. the one getting un-mapped. her moment. πŸ‘‘

πŸ’– DESCRIPTION πŸ’–

so here's the tea, and it's genuinely important: there might be multiple users of that mapping. like, several besties sharing the same locker. so dsa_lag_unmap does not just yank it β€” it only removes the mapping if there are no other references to it. 🫢

no cap, that's the whole rule. reference count hits zero? mapping's gone. somebody else still holding on? it stays. respect the refcount, periodt. πŸ’…

lowkey the most responsible function in the file and i'm obsessed with her for it ✨

πŸ¦‹ SEE ALSO πŸ¦‹

  • Kernel file ./net/dsa/dsa.c β€” the source, the mothership, the origin story 🧚
  • dsa_lag_map(9) β€” the other half of the duo, the mapping to this unmapping. they're giving complementary energies fr fr πŸ”₯

and that's the page!! πŸ’– this little gem comes to you from ./net/dsa, dated October 2026 β€” screenshot it, cite it, tell your friends, iykyk πŸ˜­πŸ’œ

πŸ“¦ where this page comes from