You attach an XDP drop program to a 25 GbE Linux server's interface. The filter works, but throughput and CPU use are no better than the iptables rule it replaced, and `ip link show` reports the attachment as xdpgeneric. What are XDP's three attach modes, and what has happened here?

## The three modes **Native (driver) mode** is what people mean by XDP. The driver implements the XDP entry point and calls your program from its NAPI poll loop, on the raw receive buffer, before allocating an `sk_buff`. Drivers with native support include mlx5, ixgbe, i40e, bnxt and virtio-net, among others; many drivers, particularly on consumer and older server hardware, have none. **Generic (SKB) mode** is a fallback implemented in shared kernel code rather than in any driver. The kernel allocates the `sk_buff` as usual and then runs your XDP program against it, presenting the same `xdp_md` context. Every verdict behaves the same way, so your program is functionally correct and you can develop against a laptop. But the entire performance argument for XDP is "decide before the skb exists", and in generic mode the skb already exists. You have added a BPF program's worth of work to the receive path and removed nothing. **Offloaded mode** hands the program to the NIC, which runs it on its own processors so packets are dropped or forwarded without ever crossing PCIe. This requires a NIC with a programmable datapath and driver support for offload; it is rare, and offloaded programs face extra restrictions on which helpers and map types they can use. ## Why you ended up in generic mode iproute2 lets you ask for a mode explicitly, or leave it to the kernel: ```bash ip link set dev eth0 xdp obj prog.o sec xdp # kernel chooses; falls back ip link set dev eth0 xdpdrv obj prog.o sec xdp # native only, or fail ip link set dev eth0 xdpgeneric obj prog.o sec xdp # force the fallback ip link set dev eth0 xdpoffload obj prog.o sec xdp # onto the NIC ip link set dev eth0 xdp off ``` The plain `xdp` keyword is the trap. It tries native, and if the driver does not implement it, quietly attaches in generic mode instead. Nothing fails; a load-time error would have told you immediately, but a successful attach tells you nothing about which mode you got. That is why the diagnosis is `ip link show` (or `bpftool net show dev eth0`) reading back the actual mode — the flag in the output is the answer. The usual causes, in order of likelihood: 1. **The driver has no native XDP support.** Confirm the driver with `ethtool -i eth0` and check whether that driver implements XDP in your kernel version. 2. **You attached to a virtual device, not the NIC.** A bond, bridge, VLAN or similar stacked device is not the same attach target as the underlying physical interface, and support differs. Attach to the device that actually receives from the wire. 3. **The kernel is too old for that driver's support**, which landed at different releases per driver. The operational lesson is to always attach with `xdpdrv` in production. If native mode is not available you want the attach to fail during deployment, not to succeed and silently deliver none of the benefit you sized the machine around. ## What native mode costs you Getting native mode is not free. Attaching an XDP program typically causes the driver to reconfigure and briefly reset the interface, so it is not a no-impact operation on a live box. `XDP_TX` and `XDP_REDIRECT` need transmit resources, so drivers commonly allocate additional TX queues when a program attaches — on a machine with a very high core count, that allocation can fail. Historically, native XDP also required the packet to fit in a single buffer, which put a ceiling on MTU and interacted badly with receive offloads; multi-buffer XDP, added in kernel 5.18, relaxes that, but only for drivers and programs that opt into it. So the correct reading of this incident is not "XDP is overhyped". It is that XDP's speed comes from *where* it runs, the mode determines where it runs, and the mode is a property of the driver, not of your program.