4. XDP技术全景：XDP程序挂载点、XDP动作码与eBPF关系

XDP（eXpress Data Path）是Linux内核中最早、最快的软件数据包处理路径。它在网络驱动层、内核协议栈之前介入，允许用户通过eBPF程序对原始数据包进行判决与转发。本章从挂载点、动作码、与eBPF的协作关系三个维度，构建XDP技术的完整全景。

4.1 XDP程序挂载点：数据包进入内核的第一站

XDP程序并非挂载在协议栈内部，而是直接附着在网络设备的驱动层接收队列上。当网卡通过DMA将数据包写入内存后，在sk_buff分配、协议栈处理之前，XDP程序即获得数据包的原始内存页指针（xdp_buff）。

挂载方式分为两种：

• 原生（Native）XDP： 直接由网卡驱动调用，性能最高，要求驱动支持XDP（如i40e、mlx5、ixgbe等）。
• 通用（Generic）XDP： 在协议栈内部模拟XDP执行，用于不支持原生XDP的驱动，性能较低但无需硬件升级。

4.2 XDP动作码：数据包的五大命运

XDP程序执行完毕后必须返回一个动作码（Action Code），内核根据该动作码决定数据包的最终处理方式。动作码定义在linux/bpf.h头文件中，共5种：

4.3 XDP与eBPF的关系：程序载体与执行引擎

XDP与eBPF是不可分割的共生关系：

• eBPF是程序载体： XDP程序使用eBPF指令集编写，通过bpf()系统调用加载到内核。
• XDP是执行上下文： eBPF程序附着在XDP挂载点上，接收xdp_buff作为输入，返回动作码作为输出。
• 共享基础设施： XDP程序可以使用eBPF的Map、Helper函数、尾调用、BPF链接等所有特性。

从代码角度看，一个典型的XDP程序结构如下：

// xdp_example.c
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_drop_icmp(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    struct ethhdr *eth = data;
    struct iphdr *ip;

    // 边界检查
    if (data + sizeof(*eth) > data_end)
        return XDP_ABORTED;

    ip = data + sizeof(*eth);
    if ((void *)ip + sizeof(*ip) > data_end)
        return XDP_ABORTED;

    // 丢弃所有ICMP包
    if (ip->protocol == IPPROTO_ICMP)
        return XDP_DROP;

    return XDP_PASS;
}

上述程序展示了XDP与eBPF的协作：SEC("xdp")标记程序类型，xdp_md是eBPF上下文，XDP_DROP/XDP_PASS是动作码，bpf_helpers.h提供eBPF辅助函数。整个程序在加载时由eBPF验证器检查安全性，然后由JIT编译为本地指令执行。

4.4 XDP动作码与eBPF Map的协同

实际生产环境中，XDP程序通常不会硬编码动作码，而是通过eBPF Map动态查询判决规则。这种设计将控制平面（用户态更新Map）与数据平面（XDP程序查询Map）分离：

// 使用Map动态决定动作码
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1024);
    __type(key, __u32);   // IP地址
    __type(value, __u32); // 动作码
} blacklist SEC(".maps");

SEC("xdp")
int xdp_dynamic_filter(struct xdp_md *ctx) {
    // ... 解析IP ...
    __u32 *action = bpf_map_lookup_elem(&blacklist, &ip_src);
    if (action)
        return *action;  // 动态返回DROP/PASS/TX/REDIRECT
    return XDP_PASS;
}

4.5 动作码选择策略与性能对比

不同动作码对CPU和内存的影响差异显著，选择策略直接影响系统吞吐量：