What Native XDP Drop Benchmarks Omit: The Cost of a Minimal Packet-Reading Path
L. Wehrberger
code ·
Comparative packet-filter evaluations often represent native XDP by a minimal XDP_DROP program. Such a program drops packets without touching the packet itself. It is therefore not equivalent to a filter that classifies packets by their contents and must inspect at least one header field. The distinction matters because filtering options further down the receive path, such as generic XDP and Netfilter, run at a point where the relevant packet data may already have been brought into the processor's cache. A native-XDP baseline that never touches the packet can thus omit a platform-dependent first-access cost that later hooks may not pay. Prior measurements of this cost differ by an order of magnitude and report no memory counters for the access itself. We measure the minimal read path on an AMD Zen 1 platform without a documented cache-injection mechanism, using an Intel 82599ES NIC with the ixgbe driver and a 512-descriptor RX ring, and compare the standard no-touch and read-data operations of xdp-bench at the native and generic hooks. Reading packet data lowers the native processing plateau from 14.29 to 10.12 Mpps and adds a median of 68 unhalted core cycles and 0.53 DRAM fills per processed packet. At the generic hook, the plateau changes only marginally, the median DRAM fill difference is zero, and the cycle difference is inconsistent across loads.