libeth_xsk_buff_add_frag(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… libeth_xsk_buff_add_frag(9) πŸ’…

okay bestie, welcome to the Kernel API Manual page for libeth_xsk_buff_add_frag(9) β€” yes that's the whole title, we're not abbreviating, we're not hiding the lore 🫢


✨ NAME ✨

libeth_xsk_buff_add_frag β€” literally just adding a frag to an XSk Rx buffer, that's the whole vibe πŸŽ€


🌸 SYNOPSIS 🌸

struct libeth_xdp_buff * libeth_xsk_buff_add_frag (struct
libeth_xdp_buff *head , struct libeth_xdp_buff *xdp );

like, look at that signature. iconic. no notes πŸ”₯


πŸ¦‹ ARGUMENTS πŸ¦‹

  • head β€” the head buffer, the main character of this whole operation πŸ‘‘
  • xdp β€” the frag buffer, the little sidekick getting attached ✨

πŸ’– DESCRIPTION πŸ’–

okay so listen β€” this is an external helper used by libeth_xsk_process_buff, and the assignment said do not call directly. like please, respect the boundary πŸ™ˆ

and ngl the important part: it frees both the main and frag buffers on error. both of them. so if something goes sideways, nothing's leaking, it's handled πŸ’… periodt.


⭐ RETURN ⭐

  • on success you get the main buffer with the frag attached β€” slay πŸ’–
  • on error you get NULL, which happens when there's no space for a new frag 😭 fr fr that's the one condition

🌈 SEE ALSO 🌈

the kernel file lives right here, go read it bestie:

./drivers/net/ethernet/intel/libeth/xsk.c

and the whole friend group of related pages:


lowkey a warning tho: again, this one's an external helper for libeth_xsk_process_buff β€” do not call directly πŸ’€ it does its own buffer cleanup on error and you don't wanna find out the hard way πŸ”₯

k that's the page!! sourced from ./drivers/net/ethernet/intel/l..., dated October 2026, and filed under libeth_xsk_buff_add_frag(9) β€” mwah, go forth and don't call it directly πŸ’œπŸ§šπŸ“

πŸ“¦ where this page comes from