net/xdp/xsk_queue.h
Source file repositories/reference/linux-study-clean/net/xdp/xsk_queue.h
File Facts
- System
- Linux kernel
- Corpus path
net/xdp/xsk_queue.h- Extension
.h- Size
- 13751 bytes
- Lines
- 509
- Domain
- Networking Core
- Bucket
- Sockets, Protocols, Packet Path, And Network Policy
- Inferred role
- Networking Core: implementation source
- Status
- source implementation candidate
Why This File Exists
Networking stack implementation surface: socket APIs, protocol dispatch, packet flow, routing, filtering, and network namespaces.
- Networking stack implementation surface: socket APIs, protocol dispatch, packet flow, routing, filtering, and network namespaces.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hlinux/if_xdp.hnet/xdp_sock.hnet/xsk_buff_pool.hxsk.h
Detected Declarations
struct xdp_ringstruct xdp_rxtx_ringstruct xdp_umem_ringstruct xsk_queuestruct parsed_descfunction xskq_cons_read_addr_uncheckedfunction xp_unused_options_setfunction xp_aligned_validate_descfunction xp_unaligned_validate_descfunction xp_validate_descfunction xskq_has_descsfunction xskq_cons_is_valid_descfunction xskq_cons_read_descfunction xskq_cons_release_nfunction parse_descfunction xskq_cons_read_desc_batchfunction __xskq_cons_releasefunction __xskq_cons_peekfunction xskq_cons_get_entriesfunction xskq_cons_nb_entriesfunction xskq_cons_peek_addr_uncheckedfunction xskq_cons_peek_descfunction xskq_cons_get_entriesfunction xskq_cons_cancel_nfunction xskq_cons_present_entriesfunction xskq_get_prodfunction xskq_prod_nb_freefunction xskq_prod_is_fullfunction xskq_prod_cancel_nfunction xskq_prod_reservefunction xskq_prod_reserve_addrfunction xskq_prod_write_addrfunction xskq_prod_write_addr_batchfunction __xskq_prod_reserve_descfunction xskq_prod_reserve_descfunction __xskq_prod_submitfunction xskq_prod_submitfunction xskq_prod_submit_nfunction xskq_prod_is_emptyfunction xskq_nb_invalid_descsfunction xskq_nb_queue_empty_descs
Annotated Snippet
struct xdp_ring {
u32 producer ____cacheline_aligned_in_smp;
/* Hinder the adjacent cache prefetcher to prefetch the consumer
* pointer if the producer pointer is touched and vice versa.
*/
u32 pad1 ____cacheline_aligned_in_smp;
u32 consumer ____cacheline_aligned_in_smp;
u32 pad2 ____cacheline_aligned_in_smp;
u32 flags;
u32 pad3 ____cacheline_aligned_in_smp;
};
/* Used for the RX and TX queues for packets */
struct xdp_rxtx_ring {
struct xdp_ring ptrs;
struct xdp_desc desc[] ____cacheline_aligned_in_smp;
};
/* Used for the fill and completion queues for buffers */
struct xdp_umem_ring {
struct xdp_ring ptrs;
u64 desc[] ____cacheline_aligned_in_smp;
};
struct xsk_queue {
u32 ring_mask;
u32 nentries;
u32 cached_prod;
u32 cached_cons;
struct xdp_ring *ring;
u64 invalid_descs;
u64 queue_empty_descs;
size_t ring_vmalloc_size;
/* Mutual exclusion of the completion ring in the SKB mode.
* Protect: when sockets share a single cq when the same netdev
* and queue id is shared.
*/
spinlock_t cq_cached_prod_lock;
};
struct parsed_desc {
u32 mb;
u32 valid;
};
/* The structure of the shared state of the rings are a simple
* circular buffer, as outlined in
* Documentation/core-api/circular-buffers.rst. For the Rx and
* completion ring, the kernel is the producer and user space is the
* consumer. For the Tx and fill rings, the kernel is the consumer and
* user space is the producer.
*
* producer consumer
*
* if (LOAD ->consumer) { (A) LOAD.acq ->producer (C)
* STORE $data LOAD $data
* STORE.rel ->producer (B) STORE.rel ->consumer (D)
* }
*
* (A) pairs with (D), and (B) pairs with (C).
*
* Starting with (B), it protects the data from being written after
* the producer pointer. If this barrier was missing, the consumer
* could observe the producer pointer being set and thus load the data
* before the producer has written the new data. The consumer would in
* this case load the old data.
*
* (C) protects the consumer from speculatively loading the data before
* the producer pointer actually has been read. If we do not have this
* barrier, some architectures could load old data as speculative loads
* are not discarded as the CPU does not know there is a dependency
* between ->producer and data.
*
* (A) is a control dependency that separates the load of ->consumer
* from the stores of $data. In case ->consumer indicates there is no
* room in the buffer to store $data we do not. The dependency will
* order both of the stores after the loads. So no barrier is needed.
*
* (D) protects the load of the data to be observed to happen after the
* store of the consumer pointer. If we did not have this memory
* barrier, the producer could observe the consumer pointer being set
* and overwrite the data with a new value before the consumer got the
* chance to read the old value. The consumer would thus miss reading
* the old entry and very likely read the new entry twice, once right
* now and again after circling through the ring.
*/
/* The operations on the rings are the following:
*
* producer consumer
Annotation
- Immediate include surface: `linux/types.h`, `linux/if_xdp.h`, `net/xdp_sock.h`, `net/xsk_buff_pool.h`, `xsk.h`.
- Detected declarations: `struct xdp_ring`, `struct xdp_rxtx_ring`, `struct xdp_umem_ring`, `struct xsk_queue`, `struct parsed_desc`, `function xskq_cons_read_addr_unchecked`, `function xp_unused_options_set`, `function xp_aligned_validate_desc`, `function xp_unaligned_validate_desc`, `function xp_validate_desc`.
- Atlas domain: Networking Core / Sockets, Protocols, Packet Path, And Network Policy.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.