高性能网络技术演进与创新探索:RDMA、eBPF/XDP 深度解析及 LSF/MM/BPF 2023 专题演讲

一、 RDMA 技术详解:原理、历史演进与优缺点

1.1 RDMA 核心概念与工作原理

RDMA (Remote Direct Memory Access,远程直接内存访问) 是一种专为突破传统 TCP/IP 网络协议栈性能瓶颈而设计的高性能网络通信技术。

在传统 Linux TCP/IP 网络栈中,数据接收需要经过多次内核上下文切换和内存复制:网卡通过 DMA 将数据包写入内核缓冲区,CPU 触发中断,内核网络协议栈进行校验解包,最后将数据从内核空间复制到用户空间内存。这一过程消耗大量 CPU 算力,并引入了毫秒或微秒级的延时。

RDMA 的核心思想在于内核旁路 (Kernel Bypass)零拷贝 (Zero-Copy)

  • 零拷贝 (Zero-Copy): 网卡(HCA)直接通过 DMA 在远程与本地应用程序内存区域(Memory Region)之间传输数据,无需经过内核中间缓冲区。

  • 内核旁路 (Kernel Bypass): 应用程序通过用户态库(如 libibverbs)直接向硬件网卡提交提交队列(SQ/RQ),跳过内核协议栈和系统调用。

  • 异步 Verbs API & 中断合并: 使用异步 Verbs 接口代替同步 Socket,同时在消息级别进行中断合并,显著降低了 CPU 占用。

1.2 RDMA 技术历史与演进路线

RDMA 的演进体现了从"独立专有硬件网络"向"标准通用以太网"融合的趋势:

  1. Infiniband (IB): 诞生于 1999 年,由 IBTA 规范化。提供专有的物理层、链路层、网络层及硬件 HCA。具备极低延时(亚微秒级)与高吞吐,但建设与运维成本高昂,且与现有以太网不兼容。

  2. RoCEv1 (RDMA over Converged Ethernet v1): 2010 年发布,将 InfiniBand 报文直接封装在以太网链路层(EtherType 0x8915)。由于缺少 L3 IP 路由能力,仅能运行于同一个二层广播域(LAN),限制了其大规模推广。

  3. RoCEv2 (Routable RoCE / RRoCE): 2014 年发布,改用标准 UDP/IP 进行封装(使用保留 UDP 目的端口 4791)。RoCEv2 具备完整的 L3 跨网段路由能力,成功融入现有的 IP 数据中心网络,成为公有云与 AI/HPC 集群的主流选择。Linux 4.5 内核开始原生支持 RoCEv2。

  4. SoftRoCE (RXE): IBTA RoCEv2 规范的纯软件内核驱动实现。SoftRoCE 允许在任何标准以太网卡(如 Intel E810)上运行 RoCEv2 协议栈,极大降低了 RDMA 的开发、调试及部署门槛。

1.3 RDMA 优缺点评估

维度 优势 (Advantages) 劣势与挑战 (Disadvantages)
性能 极低延时与高吞吐: 绕过内核,实现微秒级甚至亚微秒级传输。 无损网络要求高: RoCEv2 依赖无损以太网环境(需配置 PFC、ECN),极易产生拥塞风暴。
CPU 消耗 极致低 CPU 占用: 硬件处理传输层逻辑,释放 CPU 集中用于业务计算。 开发难度高: 异步 Verbs 编程逻辑复杂,内存注册(MR)与安全管理繁琐。
架构 内存直连: 适合分布式存储、RDMA 数据库及大模型并行训练。 可观测性差: 绕过内核导致传统工具(如 tcpdump、iptables)失效,运维排查极为困难。

二、 eBPF / XDP 技术详解:原理、历史演进与优缺点

2.1 eBPF/XDP 核心概念与工作原理

  • eBPF (Extended Berkeley Packet Filter): 允许在 Linux 内核中安全地运行沙盒化自定义程序,无需修改内核代码或加载内核模块。

  • XDP (eXpress Data Path): 于 Linux 4.8 引入,是基于 eBPF 的高性能包处理路径。XDP 程序运行于网卡驱动极早期(NAPI 接收环形缓冲区分配 sk_buff 之前)。它赋予了 Linux 内核在硬件最底层对数据包进行快速处理与动态拦截的能力。

XDP 程序根据返回值执行以下核心 Action:

  • XDP_DROP / XDP_ABORT: 极速丢弃数据包(常用于秒级 DDoS 防御)。

  • XDP_PASS: 将数据包放行,继续构建 skb 递交至内核传统网络栈。

  • XDP_TX: 将数据包从当前网卡原路发回。

  • XDP_REDIRECT: 绕过内核栈,重定向到其他网卡、CPU 核心或用户态 AF_XDP 套接字。

2.2 eBPF/XDP 历史与演进路线

  1. cBPF 时代 (1992): 仅包含 2 个寄存器,主要用于 tcpdump 过滤规则。

  2. eBPF 演进 (2014, Linux 3.18): 扩展至 10 个 64 位寄存器,引入 BPF Map 与 Verifier 验证器,从简单包过滤演变为内核通用可编程引擎。

  3. XDP 合并 (2016, Linux 4.8): 解决了 Linux 内核在超高吞吐网络下处理包性能不如 DPDK 的痛点,保留内核安全性的同时实现了超高性能。

  4. 云原生生态爆发 (2018-至今): eBPF/XDP 成为云原生网络(Cilium)、高性能负载均衡(Katran)及安全观测的标准基础设施。

2.3 eBPF/XDP 优缺点评估

维度 优势 (Advantages) 劣势与挑战 (Disadvantages)
性能 极早期处理: 在 SKB 分配前处理,吞吐性能极高。 硬件驱动依赖: 高性能 Native 模式需要网卡驱动实现 XDP Hook。
安全性 Verifier 机制: 内核校验器确保程序不会死循环或导致系统崩溃。 复杂性限制: 受限于 Verifier 的严格检查,复杂的算法与逻辑难以编写。
灵活性 热更新与动态可编程: 无需重启系统或重新编译内核,实时加载/卸载。 无传输层状态管理: XDP 仅处理单包,不自带复杂的重传与 TCP 状态机管理。

三、 LSF/MM/BPF 2023 专题:Zhu Yanjun 的 "XDP(eBPF) with RDMA(RXE)" 创新探讨

3.1 议题背景与技术痛点

在 2023 年 3 月 16 日举行的 Linux 内核顶级会议 LSF/MM/BPF 2023 上,作者 Zhu Yanjun (朱彦军) 介绍了题为 《XDP(eBPF) with RDMA(RXE)》 的技术方案。

核心痛点:

硬件 RDMA 完全绕过内核,缺少灵活的观测与管控手段。而在使用 SoftRoCE (RXE) 软件实现时,RoCEv2 报文(UDP 4791 端口)虽然在内核中走 UDP 网络栈,但传统的 XDP 只能挂载在网卡驱动的最前端,无法灵活地对 SoftRoCE 驱动收发路径(TX/RX Path)中的 RDMA 报文进行精细化抓包、解包分析与可编程流量干预。

3.2 整体架构设计 (High Level Design)

Zhu Yanjun 提出了将 XDP eBPF 的强大解析能力融入 SoftRoCE (RXE) 架构的完整设计:

复制代码
[ User Space ]   +-----------------------+     +-----------------------+
                 |  xdp_rdma_pkts_user   |     |   RDMA Application    |
                 +-----------+-----------+     +-----------+-----------+
                             |                             |
                             | bpf_xdp_attach()            | libibverbs / rping
                             v (XDP_FLAGS_RDMA)            v
-----------------------------|-----------------------------|-----------------------
[ Kernel Space ]             v                             v
                       +-----------+                 +-----------+
                       | netdev    |                 |  ib_core  |
                       | (ICE/E810)|                 +-----+-----+
                       +-----+-----+                       |
                             |                             v
                             | transfers prog       +-----------+
                             +--------------------->| rxe driver| (SoftRoCE)
                                                    +-----+-----+
                                                          |
                                         +----------------+----------------+
                                         |                                 |
                                         v                                 v
                                  [ RXE Recv Path ]                [ RXE Xmit Path ]
                                  (Parse/Pass to RDMA)             (Clone SKB to Queue)

3.3 关键实现细节解析

1. 新增标志位 XDP_FLAGS_RDMA

为了让系统能够区分常规的网卡 XDP 程序与作用于 SoftRoCE 的 RDMA XDP 程序,方案中新增了 XDP_FLAGS_RDMA 标志位:

复制代码
#define XDP_FLAGS_REPLACE    (1U << 4)
#define XDP_FLAGS_RDMA       (1U << 5)   /* 新增:专门用于指定 RDMA/RXE 的 XDP 标志 */

#define XDP_FLAGS_MASK       (XDP_FLAGS_UPDATE_IF_NOEXIST | \
                              XDP_FLAGS_MODES | XDP_FLAGS_REPLACE | \
                              XDP_FLAGS_RDMA)

用户态通过 bpf_xdp_attach(idx, fd, xdp_flags | XDP_FLAGS_RDMA, NULL) 传递此标志。

2. 用户空间数据包解析结构体

针对 RDMA 复杂的多层协议头(IP + UDP + IB BTH + RETH + Payload),在用户态定义了核心解析结构 struct rxe_opcode_info

复制代码
struct rxe_opcode_info {
    char      *name;
    int        length;
    int        offset[NUM_HDR_TYPES];
};

/* 针对全量 Opcode (RC, RD, UC, UD) 进行映射初始化 */
struct rxe_opcode_info rxe_opcode[RXE_NUM_OPCODE] = {
    [IB_OPCODE_RC_SEND_FIRST] = {
        .name   = "IB_OPCODE_RC_SEND_FIRST",
        .length = RXE_BTH_BYTES,
        .offset = {
            [RXE_BTH]     = 0,
            [RXE_PAYLOAD] = RXE_BTH_BYTES,
        }
    },
    // ... RC / RD / UC / UD 对应的完整偏移定义
};
3. 内核 NIC 驱动层拦截与转移 (以 Intel ICE 驱动为例)

在网卡驱动的 XDP_SETUP_PROG 处理逻辑中,优先检查 XDP_FLAGS_RDMA

复制代码
case XDP_SETUP_PROG:
    if (xdp->flags & XDP_FLAGS_RDMA) {
        /* 将 xdp_prog 绑定到 netdev 并触发网络设备状态变更事件 */
        old_prog = xchg(&dev->xdp_prog, xdp->prog);
        if (old_prog)
            bpf_prog_put(old_prog);

        netdev_state_change(dev);
        return 0;
    }
    /* 规则 XDP 则调用网卡原本的 ice_xdp_setup_prog */
    return ice_xdp_setup_prog(vsi, xdp->prog, xdp->extack);
4. SoftRoCE (RXE) 驱动收发路径的 Hook 与处理
  • 驱动初始化流程: 当 SoftRoCE 挂载到网卡上时,通过接收 NETDEV_CHANGE 事件完成 RXE 内部 XDP 收发路径的初始化;若 Attach 时 SoftRoCE 已运行,则在配置时动态挂钩。

  • 发送路径 (XMIT Path): 当 RDMA 栈生成数据包时,装载进 UDP 载荷的同时将 SKB 复制(Clone)到专门的 XDP SKB 队列中。XDP 程序解析后释放该克隆包,原始报文正常发往网络,实现无损的发送端抓包。

  • 接收路径 (RECV Path): 网卡接收到 UDP 4791 端口报文后转交 RXE,RXE 接收路径直接调用 rxe_xdp_prog 进行解析与处理(返回 XDP_PASS 时继续递交给 RDMA 栈)。

3.4 演示与测试结果 (Demo Analysis)

在演示中,Zhu Yanjun 在 Ubuntu 环境下通过 rping 工具完成了方案验证:

复制代码
Pkt len: 124 bytes. IP hdr:
struct iphdr {
        __be32  saddr; 192.168.1.149
        __be32  daddr; 192.168.1.156
};
udp hdr:
struct udphdr {
        __be16  source; 62933
        __be16  dest;   4791
        __be16  len;    104
        __sum16 check;  0
};
IB_OPCODE_RC_RDMA_WRITE_ONLY
struct rxe_bth {
        __u8            opcode; 0xa
        __u8            flags;  0x0
        __be16          pkey;   0xffff
        __be32          qpn;    0x16
        __be32          apsn;   0x22ea59
};
RXE_RETH
struct rxe_reth {
        __be64          va;
        __be32          rkey;
        __be32          len;
};
RXE_PAYLOAD
rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr00...

测试结果表明,该方案成功精准提取并输出了 RoCEv2 协议各层头部元数据与有效载荷,验证了 eBPF/XDP 在 RDMA 协议栈中精细化观测的可行性。

四、 总结

Zhu Yanjun 提出的 XDP(eBPF) with RDMA(RXE) 方案,巧妙地融合了 RDMA 的高性能传输特性与 eBPF/XDP 的动态可编程与可观测优势。该方案不仅改善了软件 RDMA 环境下的调试与监控体验,也为未来高性能 SmartNIC/DPU 架构下的 RDMA 流量管理提供了前瞻性的思路。

相关推荐
名字还没想好☜1 小时前
Python itertools 实战:用 groupby、chain、islice 优雅处理大数据流
linux·windows·python·迭代器·itertools
ziguo11224 小时前
深入浅出 C/C++ 数据类型:从入门到踩坑
linux·c语言·c++·windows·visual studio
无垠的广袤4 小时前
【工业树莓派 CM0 Dev Board】扩展板设计
linux·python·嵌入式硬件·pcb设计·模块化·传感器
会编程的土豆5 小时前
MySQL 入门:库、表、行、主键是什么
linux·数据库·网络协议·http
△曉風殘月〆6 小时前
如何在Linux中安装Qt开发环境
linux·运维·qt
不会就选b7 小时前
Linux之文件--fd,重定向
linux
三十岁老牛再出发7 小时前
07.26每日总结
linux·c语言·mysql
fengyehongWorld7 小时前
Linux update-alternatives命令
linux
雨的旋律20998 小时前
ubuntu2604
linux·运维·服务器