unmap_skb(9)

💅 unmap_skb — from the Kernel API Manual ✨

okay so bestie, welcome to the group chat. this is unmap_skb(9), straight out of the Kernel API Manual, and it's genuinely SO much more chill than it looks. let's get into it 🫶

---

✨ NAME ✨

unmap_skb — unmaps a packet's main body and its page fragments. that's the whole vibe. clean up after yourself, queen 💅

---

🌸 SYNOPSIS 🌸

void unmap_skb (struct sk_buff *skb , struct sge_txq *q , unsigned int
cidx , struct pci_dev *pdev );

like, copy-paste it exactly, it's giving void return, no notes, no drama, no return value whatsoever 🔥

---

🎀 ARGUMENTS 🎀

• skb — the packet. the main character, literally. everything happens to this lil guy.
• q — the Tx queue that's holding the Tx descriptors for the packet. it's the container, it's the bestie holding your stuff.
• cidx — the index of the Tx descriptor. yes it's a number, no you don't get to guess it.
• pdev — the PCI device. the hardware side of the equation 🦋

---

👑 DESCRIPTION 👑

so here's the tea: this function unmaps the main body of an sk_buff and its page fragments, if any exist. if there aren't any, she just does her thing. no big deal.

now, the why is kind of iconic. our SGLs (scatter-gather lists) have a pretty complicated structure, and we also really want to conserve space for metadata — so the info you need to unmap an sk_buff is lowkey spread all over the place. three whole locations, no cap:

• the sk_buff itself → buffer lengths
• the HW Tx descriptors → the physical addresses of the various data buffers
• the SW descriptor state → assorted indices

the send functions set up the indices for the first packet descriptor, which is exactly why we can unmap the buffers held in that first Tx descriptor right here. and by this point we've got enough information to set the state for the next Tx descriptor too. slay, honestly 💖

small heads-up about a race condition, keep reading, it's fine: it is possible to clean up the first descriptor of a packet before the send routines have written the next descriptors. but that race genuinely doesn't cause any problem. we just end up writing the unmapping info for the descriptor first. that's it. that's the whole deal ✨

---

🌈 SEE ALSO 🌈

if you want the full cinematic universe, it lives in the kernel file ./drivers/net/ethernet/chelsio/cxgb3/sge.c — and honestly? every single one of these is part of the extended lore. not me listing all of them, but also yes me listing all of them 💀

refill_rspq(9), need_skb_unmap(9), free_tx_desc(9), reclaim_completed_tx(9),
should_restart_tx(9), free_rx_bufs(9), add_one_rx_buf(9), refill_fl(9),
recycle_rx_buf(9), alloc_ring(9), t3_reset_qset(9), t3_free_qset(9),
init_qset_cntxt(9), sgl_len(9), flits_to_desc(9), get_packet(9),
get_packet_pg(9), get_imm_packet(9), calc_tx_descs(9), write_sgl(9),
check_ring_tx_db(9), write_wr_hdr_sgl(9), write_tx_pkt_wr(9),
t3_eth_xmit(9), write_imm(9), check_desc_avail(9),
reclaim_completed_tx_imm(9), ctrl_xmit(9), restart_ctrlq(9),
deferred_unmap_destructor(9), write_ofld_wr(9), calc_tx_descs_ofld(9),
ofld_xmit(9), restart_offloadq(9), queue_set(9), is_ctrl_pkt(9),
t3_offload_tx(9), offload_enqueue(9), deliver_partial_bundle(9),
ofld_poll(9), rx_offload(9), restart_tx(9), cxgb3_arp_process(9),
rx_eth(9), lro_add_page(9), handle_rsp_cntrl_info(9), check_ring_db(9),
is_new_response(9), process_responses(9), napi_rx_handler(9),
process_pure_responses(9), handle_responses(9), t3_intr_handler(9),
t3_sge_err_intr_handler(9), sge_timer_tx(9), sge_timer_rx(9),
t3_update_qset_coalesce(9), t3_sge_alloc_qset(9),
t3_start_sge_timers(9), t3_stop_sge_timers(9), t3_free_sge_resources(9),
t3_sge_start(9), t3_sge_stop_dma(9), t3_sge_stop(9), t3_sge_init(9),
t3_sge_prep(9)

---

and that's the page!! 🧚 no exit statuses, no environment variables, no signals, she is refreshingly low-maintenance. go unmap some buffers, bestie, you're gonna do amazing 💜

sourced from ./drivers/net/ethernet/chelsio..., dated October 2026 — that's the sign-off, mwah 💋 unmap_skb(9) out. 🎀