Follow an AF_XDP Packet Through Shared Memory and Completion Rings

Identify the socket's active transfer mode

AF_XDP is a Linux socket interface through which an XDP program can redirect incoming traffic to an application. This explanation uses Linux v6.17 documentation and matching implementation, rather than assuming a particular installed kernel or adapter.

An XDP-capable driver does not settle whether the AF_XDP socket uses copy or zero-copy transfer. Linux v6.17's introductory SKB/DRV wording does not describe every transfer path: its detailed mode sections explicitly document zero-copy and copy fallback.

In the v6.17 implementation, an unforced attempt can fall back to copy mode if zero-copy setup is unavailable. XDP_COPY requests copy mode; XDP_ZEROCOPY requires zero-copy or failure. The XDP_OPTIONS socket query reports active zero-copy through its XDP_OPTIONS_ZEROCOPY flag. These names identify evidence a responsible software provider can explain; they are not a setup procedure.

For a buyer, successful socket operation and successful zero-copy qualification therefore answer different questions. An offer that permits fallback may retain packet access while leaving the promised copy avoidance unestablished.

References: [K1][K2][K3][K4]

Locate the payload separately from its descriptor

UMEM is application-allocated memory registered with the kernel and divided into frames. An RX or TX descriptor identifies data by its UMEM address offset and length, with an options field for control information. The descriptor points to the bytes; it is not a second payload buffer.

The matching v6.17 receive implementation makes the copy boundary concrete. In its copy path, the kernel obtains a UMEM-backed destination and copies incoming XDP data into it before exposing an RX descriptor. In the zero-copy receive path, it exposes the existing UMEM-backed frame through a descriptor instead. The avoided operation is that receive-data copy into UMEM.

Sharing a region for receive and transmit can also let an application submit the received bytes for transmission without first relocating them into a separate application transmit buffer. That opportunity can exist even when ingress used copy mode. The two avoided copies have different boundaries.

Accordingly, an AF_XDP zero-copy claim describes a particular host packet path. It supplies neither a NIC-to-GPU-memory result nor a promise that later application processing makes no copies.

References: [K1][K2][K3]

Follow a receive frame from FILL to application use

Start with a free frame the application may reuse. Publishing its address through FILL hands it to the kernel for receive use. When received data is exposed through RX, the application consumes the descriptor and can use the referenced bytes.

Reading and releasing the RX entry frees a descriptor slot. It does not automatically return the underlying frame to receive supply. The application may retain that frame while processing its contents, recycle it through FILL when no longer needed, or submit it through TX. A frame recycled after receive-only use does not need a transmit completion.

This distinction matters when evaluating a buffer shortage. Space for more RX descriptors does not establish that more frames have been supplied for reception. Ring capacity and available packet storage are separate quantities. The linked RSS and NAPI guides address queue selection and notification/polling; this account follows the storage those mechanisms ultimately serve.

References: [K1][K2]

Follow transmit until the frame returns

When the application submits a frame through TX, it must keep that storage unavailable for conflicting reuse until COMPLETION returns it. Kernel consumption of the TX descriptor can make its ring slot available earlier. It does not establish that the frame may be overwritten or offered for reception.

COMPLETION provides returned UMEM addresses. After consuming the relevant return, the application can reuse that frame for receive supply or another transmission. The v6.17 generic transmit implementation distinguishes TX-entry consumption from later completion publication, reinforcing the difference between a ring slot and its referenced storage.

The completion boundary is local buffer lifetime. In the v6.17 generic transmit path, a kernel packet object can complete even when dropped without being sent. Completion therefore does not prove successful transmission, remote application receipt or remote processing. Evidence for a completed application exchange must reach that separate endpoint.

References: [K1][K2]

Account for 32 unique frames without counting one twice

Consider a fictional, valid single-socket arrangement with both receive and transmit and a UMEM containing 32 distinct, non-overlapping frames. Label them F0 through F31. At the stipulated snapshot, every frame belongs to exactly one of the following groups, and there are no additional pending RX or COMPLETION entries. The labels identify storage, not ring slots or packet numbers.

F0-F7 are eight kernel-owned receive-supply frames previously offered through FILL, with none yet returned through RX. They may already have left the FILL ring; their ownership still prevents application reuse.

F8-F15 are eight received frames whose RX descriptors the application has read and released. The application retains their data for further work. The RX slots can be free while these frames remain occupied.

F16-F23 are eight frames submitted for transmission whose COMPLETION returns have not yet arrived. They remain outstanding even if the kernel has consumed their TX descriptors.

F24-F31 are eight free application-owned frames with no retained data or outstanding submission. They are available for a new use, but have not yet been offered to the kernel.

The account is 8 receive-supply + 8 application-held receive + 8 outstanding transmit + 8 free = 32 unique frames. It would be wrong to add another eight because TX slots became available: those slots refer to frames already counted in the outstanding group.

Now stipulate that the application finishes using F8-F11 and offers those four frames through FILL. With no other transition, the groups become 12 receive-supply, 4 retained receive, 8 outstanding transmit and 8 free. The total remains 32.

Next stipulate that completion returns for F16-F18 arrive and the application consumes them into its free pool. Again allowing no other transition, the groups become 12 + 4 + 5 + 11 = 32. The free pool grows by three; no new memory was created.

These figures describe an ownership account, with no elapsed time, ring-size recommendation or measured result. They also supply no packet total. Supported multi-buffer operation can represent one packet with several frames; the v6.17 descriptor continuation flag links those frames. This example deliberately counts storage rather than assuming one frame per packet.

References: [K1][K2][K3]

Evaluate copy avoidance and frame lifetime together

The useful proposal describes both where bytes move and when their storage returns. Ask the provider to identify the adapter, driver, kernel, queue and application path covered by the offer, explain its active transfer mode, and distinguish that from a device's supported capabilities. A zero-copy requirement needs evidence about the socket actually used for the covered traffic.

Then have the application owner explain which frames can coexist in receive supply, retained processing and outstanding transmission. In the fictional snapshot, 32 allocated frames coexist with only eight free frames. Total allocation alone would conceal the immediate reuse constraint. Conversely, a low free count without the other states would leave its cause unresolved.

Count the underlying storage once. The v6.17 guidance warns that supplying one frame to FILL and TX concurrently can let receive overwrite data being transmitted. Sharing UMEM does not create another copy of that frame or another independent owner entitled to overwrite it.

Compare any performance promise using workload evidence at the required application endpoint. A valid ownership account explains storage availability; the supplier must still establish the claimed application result.

References: [K1][K4]

Use the selected physical connections for a cabling inquiry

When the selected host arrangement also needs cabling work, Leviathan's Structured Cabling & Fiber Installation service provides the relevant physical next step. Share approved endpoints and routes, specified compatible assemblies, materials responsibilities, access constraints and required labels and connection records through the service and project-inquiry links below.

AF_XDP integration, frame management, driver configuration and application verification remain with the appointed software and network owners. This article supports a technical purchasing decision; physical work requires its own agreed scope and authorization.

References: [L1]