In Linux XDP (eXpress Data Path), where in the packet receive path does an XDP program run, and what do the return codes XDP_PASS, XDP_DROP, XDP_TX, XDP_REDIRECT and XDP_ABORTED each tell the driver to do?

## Where the hook sits A NIC writes an incoming frame into a receive ring and raises an interrupt. The driver's NAPI poll routine walks that ring, and normally the next thing it does is allocate an `sk_buff` — the kernel's per-packet metadata structure — and hand it to `netif_receive_skb()`, from where the packet travels through the tc ingress hook, netfilter, routing, the transport layer and finally into a socket. XDP inserts a call *before* that allocation. In native mode the driver invokes the attached BPF program directly on the receive buffer, so if the verdict is "drop", the kernel never built any per-packet state to throw away. This is the whole performance story: the cost of a dropped packet collapses from "allocate an skb, walk several layers, free it" to "run a few hundred instructions and recycle the page". Published numbers for simple XDP drop programs on a single core sit in the tens of millions of packets per second; the equivalent netfilter rule is an order of magnitude slower. ## The context object The program receives a `struct xdp_md`. The important fields are `data` and `data_end`, both integers you cast to pointers, plus `data_meta` for a small scratch area you can hand to a later tc program, and `ingress_ifindex` and `rx_queue_index` for the arrival point. There is no protocol parsing done for you and no metadata: you are looking at raw bytes starting at the Ethernet header, and every read must be preceded by a bounds check against `data_end` or the program will not load. ## The five verdicts `XDP_PASS` means "not my business" — build the skb and continue up the stack normally. A real filter passes the overwhelming majority of traffic, so this is the common path. `XDP_DROP` frees the buffer on the spot. Nothing further in the kernel sees the packet, which has an important consequence: tools that tap the stack later, such as tcpdump, will not show it either. Keep your own counters in a map if you want to know what you dropped. `XDP_TX` retransmits the frame out of the *same* interface it arrived on. It cannot choose another device. Because the program is operating below the routing layer, nothing rewrites the Ethernet header for you — if you are bouncing a packet back, you swap the source and destination MAC addresses yourself. This is the primitive behind XDP load balancers and behind trivial things like an in-driver ICMP echo responder. `XDP_REDIRECT` is the general escape hatch. Combined with `bpf_redirect_map()` it can push the frame to another network device, to another CPU for further processing, or into an AF_XDP socket for a userspace program. Redirecting to a different netdev requires that device's driver to implement the transmit-side XDP entry point, so not every target works. `XDP_ABORTED` drops the packet like `XDP_DROP` but declares the drop to be an error. It fires the `xdp_exception` tracepoint, which is what you attach to when you want to know that your program hit an impossible branch. Use it in the arms that should never be taken — a failed bounds check, a malformed header — and never as your ordinary drop. ## Attaching and inspecting Attachment is a property of a network device, not of a qdisc: ```bash ip link set dev eth0 xdp obj xdp_drop.o sec xdp ip link show dev eth0 # shows the attached mode and prog id bpftool net show dev eth0 # same, from the bpftool side ip link set dev eth0 xdp off ``` Because it is per-device and ingress-only, XDP has no say over anything the host transmits. Outbound filtering belongs to the tc egress hook instead.