Understanding eBPF XDP: High-Performance Packet Processing at the Kernel Edge

Introduction

In the era of cloud-native infrastructure and 100Gbps+ network interfaces, traditional kernel networking stacks have become a bottleneck. The Linux kernel networking path, with its layers of abstraction, protocol processing, and memory copies, simply cannot keep up with modern throughput demands. Enter eBPF XDP (eXpress Data Path) — a revolutionary framework that enables programmable packet processing at the earliest possible point in the kernel, right after the network interface card (NIC) delivers a packet.

XDP allows developers to attach eBPF programs directly to the NIC driver's receive path, making decisions about individual packets before they enter the kernel's networking stack. This approach achieves packet processing rates that were previously only possible with specialized hardware or kernel bypass technologies like DPDK.

What is XDP?

XDP is the lowest layer in the Linux kernel's networking stack where eBPF programs can be attached. An XDP program is executed for every incoming packet, right at the driver level. The program has direct access to the raw packet data and can make one of five decisions:

• XDP_DROP — Immediately drop the packet (useful for DDoS mitigation)
• XDP_PASS — Pass the packet to the kernel's normal networking stack
• XDP_TX — Transmit the packet back out the same NIC it arrived on
• XDP_REDIRECT — Forward the packet to another NIC or CPU via XDP
• XDP_ABORTED — Indicate an error (tracepoint is fired)

How XDP Achieves Extreme Performance

The performance gains of XDP come from several architectural advantages:

1. Early Packet Processing

By processing packets at the driver level, XDP avoids the overhead of sk_buff allocation, queuing discipline processing, and protocol layer traversal. This alone saves thousands of CPU cycles per packet.

2. No Memory Allocation Per Packet

XDP programs operate directly on the DMA buffer provided by the NIC driver. There is no per-packet memory allocation, which eliminates a significant source of latency and cache pressure. The eBPF verifier ensures safe access to this memory region.

3. Batch Processing and Direct Memory Access

Modern NIC drivers support receive packet steering (RPS) and multiple receive queues. XDP programs can process packets in batches, leveraging CPU cache locality. Programs can also access packet data with zero copy.

4. Just-In-Time Compilation

eBPF programs are verified for safety at load time, then JIT-compiled to native machine code. On x86_64, an XDP program compiles down to efficient native instructions that execute directly on the CPU — there is no interpreter overhead.

5. Driver-Level Optimization

XDP takes advantage of driver-specific optimizations. For example, the i40e, mlx5, and virtio_net drivers provide native XDP support with pre-allocated packet buffers, enabling zero-copy packet processing entirely within the driver.

Writing an XDP Program

Let us walk through a practical example — a simple XDP program that drops all UDP packets on port 53 (DNS) from a specific source IP:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>

SEC("xdp")
int xdp_dns_filter(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = data + sizeof(*eth);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    if (ip->protocol != IPPROTO_UDP)
        return XDP_PASS;

    struct udphdr *udp = (void *)ip + sizeof(*ip);
    if ((void *)(udp + 1) > data_end)
        return XDP_PASS;

    /* Drop DNS queries from specific source (203.0.113.50) */
    __u32 blocked_ip = bpf_htonl(0xCB007132);
    if (ip->saddr == blocked_ip && udp->dest == bpf_htons(53)) {
        return XDP_DROP;
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

The program checks bounds before every access — the eBPF verifier enforces this to prevent out-of-bounds reads. This is a safety mechanism that eliminates entire classes of kernel vulnerabilities.

Real-World Applications

DDoS Mitigation at Line Rate

Projects like Facebook's Katran L4 load balancer use XDP to process traffic at 100Gbps+ per server. By making forwarding decisions in XDP, they achieve millions of packets per second per core without kernel bypass.

Cloud-Native Networking with Cilium

Cilium uses XDP and tc (traffic classifier) eBPF programs to provide networking, security, and observability for Kubernetes clusters. Its XDP-based Layer 3/4 load balancer can handle millions of connections with consistent latency.

Intrusion Detection and Security

Security tools leverage XDP for real-time packet filtering. Because XDP programs can drop malicious traffic before it reaches the kernel stack, they provide an effective first line of defense against network attacks.

Traffic Monitoring and Observability

XDP programs can aggregate statistics, sample packets, and export telemetry data to user space via eBPF maps. This enables deep network visibility without modifying packet contents or impacting performance.

Performance Benchmarks

In benchmark tests, XDP demonstrates remarkable throughput:

• Single-core packet forwarding: >10 million packets per second (Mpps) with minimal CPU utilization
• DDoS rate limiting: Can filter 40Gbps+ of attack traffic on a single CPU core
• Latency: Sub-microsecond processing per packet, compared to 5-20 microseconds for the traditional kernel path
• Comparison to DPDK: XDP achieves 80-90% of DPDK's raw throughput while maintaining full kernel integration

XDP vs DPDK: A Pragmatic Comparison

While DPDK offers raw performance through complete kernel bypass, XDP provides a compelling alternative:

• Kernel integration: XDP works with existing kernel networking, routing, and filtering tools
• Development simplicity: eBPF programs can be dynamically loaded and unloaded without kernel recompilation or module loading
• Safety: The eBPF verifier prevents crashes, infinite loops, and memory corruption
• Hardware agnostic: XDP programs work across different NIC drivers (with driver-specific optimizations)
• Debugging: Rich debugging tools (bpftool, perf probes) vs DPDK's more manual debugging approach

Advanced Patterns: XDP_REDIRECT and Multi-Queue NICs

Modern NICs have multiple receive and transmit queues (RSS — Receive Side Scaling). XDP programs can use XDP_REDIRECT to forward packets to specific CPU cores or even different NICs. This enables:

• Per-CPU connection tracking without cache contention
• Hardware-accelerated NAT and load balancing
• Zero-copy packet forwarding between interfaces
• Service mesh sidecar acceleration (as used in Cilium Service Mesh)

The XDP Ecosystem in 2026

The eBPF ecosystem has matured significantly:

• Hardware offload: Netronome and AMD/Pensando NICs support XDP offloading, moving program execution to the NIC
• CO-RE (Compile Once — Run Everywhere): libbpf and BTF enable XDP programs to run across different kernel versions without recompilation
• XDP multi-attach: Multiple programs can chain on the same interface
• AF_XDP: High-performance socket for exchanging packets between user space and kernel space
• Widespread cloud adoption: Major cloud providers use XDP internally for virtual networking and security

Conclusion

XDP represents a paradigm shift in Linux networking — it brings programmability to the kernel's critical fast path without sacrificing safety or maintainability. For infrastructure engineers building high-performance network functions, XDP offers the best of both worlds: DPDK-class performance with kernel-native integration.

As hardware speeds continue to increase (400Gbps NICs are now common, terabit-class on the horizon) and application latency requirements become more stringent, XDP is becoming indispensable for modern cloud infrastructure. The future of networking is programmable, and XDP is leading the way.