skb_pp_frag_ref(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

Okay bestie, this is skb_pp_frag_ref(9) from the Kernel API Manual, and it is here to explain one very specific skb ref-count move. One-line name-card energy:

skb_pp_frag_ref β€” Increase fragment references of a page pool aware skb. πŸ’…


✨ SYNOPSIS ✨

Here's the signature, no cap:

int skb_pp_frag_ref (struct sk_buff *skb );

That's literally it. Cute, right? πŸŽ€


🌸 ARGUMENTS 🌸

  • skb β€” page pool aware skb. That's the input, bestie. 🫢

πŸ¦‹ DESCRIPTION πŸ¦‹

So what does it do? It increases the fragment reference count β€” that's pp_ref_count β€” of an skb. The whole point is to gain fragment references only for page pool aware skbs, i.e. when skb->pp_recycle is true, and not for fragments in a non-pp-recycling skb. Lowkey important distinction. ✨

It also has a fallback: it can increase references on normal pages, because page pool aware skbs may also have normal page fragments. So yeah, it's giving "handles both cases" energy. 🫢


πŸ‘‘ SEE ALSO πŸ‘‘

This page runs with a massive squad. The kernel file ./net/core/skbuff.c is in the mix, plus every single one of these beauties:


Source/version vibes: ./net/core Β· October 2026 Β· page handle skb_pp_frag_ref(9). Bye bestie, slay your kernel debugging! πŸ’…πŸ’–

πŸ“¦ where this page comes from