In Linux eBPF networking, what does a program attached to the tc (traffic control) hook see that an XDP program does not, and when would you choose tc over XDP?

## Two hooks, two data structures The two hooks differ mainly in what has already happened to the packet when your code runs. An XDP program runs in the driver on a raw receive buffer. Its context, `struct xdp_md`, is little more than a pair of pointers into those bytes. Nothing has parsed the packet, nothing has classified it, and nothing has associated it with a socket, a process or a cgroup. A tc program runs after `sk_buff` allocation. Its context, `struct __sk_buff`, is a sanitised view of that structure and carries real metadata: `len`, `protocol`, `ifindex`, `mark`, `priority`, `tc_classid`, `cb` for passing values between programs, plus VLAN and tunnel fields. On egress you can additionally reach socket-level facts, which is how per-workload policy gets implemented. ## What the sk_buff buys, and what it costs The metadata is the point, and so is the cost. Allocating and initialising an `sk_buff` is precisely the work XDP exists to skip, so a tc drop is materially more expensive than an XDP drop. For a volumetric flood — millions of packets a second you want gone — that difference decides whether the machine survives. For a few hundred thousand packets a second of policy enforcement it is irrelevant, and the metadata is worth far more than the cycles. The skb also means you are working with the stack's own representation of the packet, so helpers can grow, shrink, encapsulate and checksum it with the stack's cooperation: `bpf_skb_store_bytes()`, `bpf_l3_csum_replace()`, `bpf_l4_csum_replace()`, `bpf_skb_adjust_room()`, `bpf_redirect()`. XDP has a narrower and lower-level set. ## Ingress, egress, and portability XDP is a receive-path hook. There is no general XDP hook on transmit, so anything you want to do to packets the host sends — outbound filtering, marking, encapsulation — is tc's job. XDP in native mode also depends on the driver implementing it. Drivers such as mlx5, ixgbe, i40e, bnxt and virtio-net do; plenty of others do not, and stacked virtual devices are their own story. tc BPF has no such requirement: it lives in generic kernel code, so it works everywhere, which matters when you are shipping something that has to run on hardware you have not seen. ## Verdicts and attachment tc programs return traffic-control action codes rather than XDP verdicts: `TC_ACT_OK` continues processing, `TC_ACT_SHOT` drops, `TC_ACT_REDIRECT` (via `bpf_redirect()`) moves the packet to another device, `TC_ACT_UNSPEC` falls through to the next filter. In *direct-action* mode — the `da` keyword — the program's return value is taken as the action verdict directly, instead of returning a classid that a separate action then interprets. Effectively everyone uses direct-action mode. Attachment goes through the `clsact` qdisc, which exists specifically to provide ingress and egress attach points without doing any queueing: ```bash tc qdisc add dev eth0 clsact tc filter add dev eth0 ingress bpf da obj tc_prog.o sec classifier tc filter add dev eth0 egress bpf da obj tc_prog.o sec classifier tc filter show dev eth0 ingress ``` Since kernel 6.6 there is also the `tcx` attach point, which gives tc programs proper `bpf_link` ownership semantics and a defined multi-program ordering, instead of the older model where two pieces of software could quietly fight over the same filter list. `bpftool net show` lists what is attached either way. ## Choosing Use XDP when the answer is "this packet should never have been built": flood drops, an L4 load balancer's forwarding path, anything measured in millions of packets per second. Use tc when you need to know something about the packet's context, when you need to act on egress, when the traffic volume does not justify the constraints, or when you cannot guarantee driver support. Systems that do both — Cilium being the well-known example — put the frontend drop and forwarding logic at XDP and the per-workload policy at tc.