Skip to main content
Wireblast runs anywhere AF_XDP runs. How fast it goes depends on your driver, and there are exactly two things worth knowing about.

​
Native versus generic

Native XDP means the driver itself runs the XDP program, right where packets arrive, before the kernel allocates anything. This is the fast path. Generic XDP (also called SKB mode) is the kernel’s fallback for drivers that don’t implement the hook. The packet gets processed the normal way first, then the program runs. It works correctly, and it’s genuinely useful for development, but it’s much slower and it drops packets under load. You don’t choose. The kernel gives you native if the driver supports it, and falls back to generic if not.
Generic mode is not a failure state. If you’re learning the tool, checking a config, or working in a namespace lab, generic is completely fine. Just don’t quote its throughput as your NIC’s capability.

​
Zero-copy versus copy

Separately from the attach mode, a driver may support zero-copy: the NIC reads packets straight out of Wireblast’s UMEM, with no memcpy anywhere in the path. When it doesn’t, you get copy mode. Everything still works; there’s just a memcpy per packet between the UMEM and the driver’s own buffers. The two settings are independent, and you can have one without the other. veth, for instance, supports native XDP but not zero-copy.

​
On AWS ENA

Jumbo frames aren’t supported on ENA. At MTU 9001 with --packet-size 9000, the bind fails:
An aligned-mode UMEM chunk can’t exceed the 4096-byte page, so no single frame can hold a 9000-byte packet. Carrying jumbo frames would need AF_XDP multi-buffer, which Wireblast doesn’t enable. ENA also won’t attach native XDP above MTU 3502 at all.

​
How to tell what you got

Run it and read the line. There’s no separate probe, because the only answer that matters is what the kernel actually granted, not what a support matrix claims. On a 10G Intel NIC:
On a veth pair:
The same information sits in the dashboard header:
If it says generic XDP, your driver has no native support, or the attach fell back for another reason, and troubleshooting has the usual causes.

​
Known-good drivers

Native XDP with zero-copy, and the cards people generally run this on: Anything else is worth trying. The list of drivers with XDP support keeps growing, and Wireblast will tell you what it got either way.

​
Queues

Wireblast opens one AF_XDP socket per receive queue and drives them in parallel, so queue count is roughly your parallelism budget. It reads the real number from /sys/class/net/<name>/queues/.
Use --queues N to use fewer. Two reasons you might:
  • Locked memory. Each queue needs its own UMEM. Fewer queues, less locked memory. This is one of the fixes Wireblast suggests when it hits the limit.
  • Isolating a variable. Rates are aggregate, so --queues 1 and --queues 12 should produce the same packet rate. If they don’t, that’s a finding.
On AWS, ENA caps XDP MTU at 3502, so an MTU at or below 3000 is the usual fix if AF_XDP won’t start. ENA drivers older than 2.17.0 also refused to attach unless combined channels were at or below half the maximum, which sudo ethtool -L ens5 combined 2 fixes. That requirement was lifted in 2.17.0, and a current instance uses all of its queues as they come.

​
Virtual interfaces

veth, and virtual interfaces generally, work fine. That’s what makes the namespace lab possible. Expect one queue, copy mode, and no link bounce on attach, since there’s no physical link to renegotiate. Throughput there tells you about your CPU and the kernel, not about a NIC. Which is exactly right when what you’re testing is your own config.