> ## Documentation Index
> Fetch the complete documentation index at: https://wireblast.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Hardware and drivers

> Native versus generic XDP, zero-copy versus copy, and how to tell which one you actually got.

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.

<Note>
  Generic mode is not a failure state. If you're learning the tool, checking a config, or working in a [namespace lab](/guides/namespace-lab), generic is completely fine. Just don't quote its throughput as your NIC's capability.
</Note>

## 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

<Warning>
  **Jumbo frames aren't supported on ENA.** At MTU 9001 with `--packet-size 9000`, the bind fails:

  ```text theme={null}
  wireblast: open AF_XDP on ens5: afxdp: could not open ens5 (4 queues):
    generic bind: queue 0: afxdp: XDP_UMEM_REG: invalid argument
  ```

  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.
</Warning>

## 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:

```text theme={null}
started: eno2: 12 queue(s), zero-copy, native XDP, driver ixgbe, rx filter none
```

On a `veth` pair:

```text theme={null}
started: wb0: 1 queue(s), copy, native XDP, rx filter none
```

The same information sits in the dashboard header:

```text theme={null}
  interface  eno2  ixgbe · 12 queue(s) · native XDP · zero-copy
```

If it says `generic XDP`, your driver has no native support, or the attach fell back for another reason, and [troubleshooting](/guides/troubleshooting) has the usual causes.

## Known-good drivers

Native XDP with zero-copy, and the cards people generally run this on:

| Driver  | Hardware                                      |
| ------- | --------------------------------------------- |
| `ixgbe` | Intel 82599 / X520 / X540 / X550, 10G         |
| `i40e`  | Intel X710 / XL710, 10-40G                    |
| `ice`   | Intel E810, 25-100G                           |
| `mlx5`  | NVIDIA/Mellanox ConnectX-4 and later, 25-100G |
| `ena`   | AWS Elastic Network Adapter                   |

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/`.

```bash theme={null}
ls /sys/class/net/eno2/queues/ | grep -c rx
```

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.

<Tip>
  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.
</Tip>

## Virtual interfaces

`veth`, and virtual interfaces generally, work fine. That's what makes the [namespace lab](/guides/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.