将 RDMA 引入容器：Soft-RoCE (RXE) 网络命名空间支持深度解析

摘要

在云原生与容器化技术普及的背景下，Linux 网络命名空间（Network Namespace, netns）构成了 Docker、Kubernetes 等容器隔离的核心基础。然而，Linux 内核中的 Soft-RoCE (RXE)（基于软件实现的 RoCEv2 协议栈驱动）在以往版本中存在严重的"命名空间盲（Namespace-Blind）"缺陷，导致其无法直接运行于隔离的容器环境中。

本文基于朱彦军（Zhu Yanjun）提出的技术修改与补丁集方案（RDMA/rxe: Add network namespace support），深入分析 RXE 驱动在网络命名空间隔离下的痛点根源、内核重构设计、技术实现细节以及实测场景。

一、 背景介绍与核心概念

1. Docker 与网络命名空间 (Net Namespace)

容器通过 Linux 内核的 cgroup（资源限制）、chroot（文件系统隔离）以及 namespace（视图隔离）来实现微服务环境。其中，网络命名空间（Net Namespace） 为每个容器提供了独立的网络协议栈，包括独立的网络设备（如 eth0、veth）、IP 地址、路由表以及 Socket 端口池，实现容器间网络流量的严格隔离。

2. RDMA 与 RoCEv2 协议

传统 TCP/IP 网络协议栈存在多次数据拷贝（Memory Copy）以及频繁的 CPU 上下文切换。RDMA（远程直接内存访问） 技术通过 Kernel Bypass（内核旁路）和零拷贝（Zero-copy）特性，大幅降低了网络延迟并减少了 CPU 占用率。

• RoCEv2（Routable RoCE） ：将传统 Infiniband 传输层封装在标准 UDP/IP 数据包中（使用系统预留的目标 UDP 端口 4791），使其具备可路由性，被广泛应用于数据中心与云原生环境。

3. Soft-RoCE (RXE) 架构

Soft-RoCE 是 RoCEv2 的纯软件实现，使得不需要专用硬件 RDMA 网卡（HCA）的普通以太网卡（如 Intel E810、Mellanox 等）也能运行 RDMA 应用：

• 用户空间 ：通过 rdma-core（libibverbs）提供通用的 Verbs API，最终调用 Soft-RoCE 用户态驱动。

• 内核空间 ：rdma_rxe 内核模块挂载在普通 NIC 驱动之上，接收来自 RDMA 栈的数据后，构造 skb 数据包并放入 UDP 载荷中，再递交给系统的 TCP/IP 协议栈发送。

二、 核心痛点：全局 Socket 导致的隔离阻断

1. 问题根源 (Root Cause)

在旧版的 RXE 内核实现中，当使用 modprobe rdma_rxe 加载 RXE 模块时，驱动会直接在主机的初始网络命名空间（init_net）中创建一个全局的 UDP Socket，并固定监听 4791 端口。

旧版旧架构瓶颈（Bottleneck）：

  Host (init_net)
  +-----------------------+     全局 RXE Socket
  | RDMA/rxe Kernel Mod   | <--- (UDP 端口 4791)
  +-----------------------+           ^
              |                       | (访问被隔离墙拒绝!)
              v                       |
   +--------------------+   +--------------------+
   | Namespace A (NS1)  |   | Namespace B (NS2)  |
   | [rxe0 Link]        |   | [rxe1 Link]        |
   +--------------------+   +--------------------+

2. 产生的后果

由于 Linux 内核对不同 Net Namespace 之间的 Socket 访问设置了严格的边界防护，运行在独立容器（自定义 Net Namespace）中的应用进程无法访问宿主机 init_net 下的全局 Socket。即便在容器内部尝试创建 RXE 链路，其数据平面也会因为无法建立 UDP 传输通道而导致通信中断。

三、 重构解决方案：Per-Namespace 资源管理

为了彻底消除这一限制，补丁方案将 RXE 驱动从"全局单套接字模型"全面重构为基于每个网络命名空间（Per-Namespace）独立管理的架构。

重构后架构（Namespace-Aware）：

  Host (init_net)
  +-------------------------------------------------------------+
  | RDMA/rxe Kernel Module (Namespace-Aware via pernet_ops)     |
  +-------------------------------------------------------------+
              |                                   |
              v                                   v
   +--------------------+               +--------------------+
   | Container A (NS1)  |               | Container B (NS2)  |
   |  [rxe0 Link]       |               |  [rxe1 Link]       |
   |  [UDP: 4791 Sock]  |               |  [UDP: 4791 Sock]  |
   +--------------------+               +--------------------+

1. 代码重构与上下文存储

• 新增 rxe_ns.c 和 rxe_ns.h 源文件，基于内核的 pernet_operations 框架实现上下文初始化。

• 引入核心数据结构 struct rxe_ns_sock，按网络命名空间 ID 保存 IPv4/IPv6 的监听 Socket 句柄：

  /* Per network namespace data */
  struct rxe_ns_sock {
      struct sock __rcu *rxe_sk4;
      struct sock __rcu *rxe_sk6;
  };

2. Socket 按需动态创建（Dynamic Lifecycle）

• 模块加载阶段 ：运行 modprobe rdma_rxe 时，驱动不再在 Host 主机上监听 UDP 4791 端口。

• 链路创建阶段 ：只有当用户在该命名空间内执行 rdma link add ... 命令创建 RXE 链路时，驱动才会在当前 Net Namespace 内部动态创建并绑定 UDP 4791 端口。

3. 链路销毁与资源回收 (Dellink Support)

• 之前的 rdma_link_ops 结构体缺乏链路删除的回调函数。

• 补丁补充扩展了 struct rdma_link_ops，增加了 dellink 回调，并实现了 rxe_del_link。当执行 rdma link del 时，能精准回收对应 Namespace 下的 Socket 及相关上下文资源。

四、 命令与行为验证

1. 宿主机操作表现

# 加载 RXE 内核模块，此时并不监听 4791 端口
# modprobe -v rdma_rxe
# ss -lun | grep 4791

# 在宿主机创建 RXE 链路，4791 端口在宿主机被创建并监听
# rdma link add rxe0 type rxe netdev eno1
# ss -lun | grep 4791
UNCONN  0  0  0.0.0.0:4791  0.0.0.0:*
UNCONN  0  0     [::]:4791     [::]:*

2. 隔离网络命名空间表现

# 新建网络命名空间 net0，此时内部没有 4791 端口
# ip netns add net0
# ip netns exec net0 ss -lun | grep 4791

# 在 net0 中创建 RXE 链路，UDP 4791 端口成功在此 namespace 内单独监听
# ip netns exec net0 rdma link add rxe1 type rxe netdev lo
# ip netns exec net0 ss -lun | grep 4791
UNCONN  0  0  0.0.0.0:4791  0.0.0.0:*
UNCONN  0  0     [::]:4791     [::]:*

3. 删除链路验证

# 执行 link del，成功释放 4791 端口
# rdma link del rxe0
# ss -lun | grep 4791
# (输出为空，说明端口与套接字资源已正确关闭)

五、 典型容器网络拓扑验证

重构后的驱动针对以下常用容器拓扑结构进行了详细的 rping 数据传输验证：

1. Host 到 Container 场景 ：宿主机与独立容器之间通过 veth pair 打通，分别创建 RXE 链路并进行 RDMA 通信。

2. Container 到 Container 对等场景 ：两个 Net Namespace（test1 与 test2）通过 veth pair 直连，两端分别运行 rping -s 服务端与 rping -c 客户端。

3. 多容器虚拟网桥 (Bridge) 场景 ：模拟 Docker / K8s 的经典网桥拓扑。创建多个 Namespace（one, two, three），通过各自的 veth 接入宿主机的 virtual-bridge 中，并在不同容器间成功执行 RDMA Ping 测试。

六、 总结

通过引入 pernet_operations 与动态 Socket 绑定机制，该改进使得 Soft-RoCE (RXE) 彻底脱离了宿主机限制，使 RDMA 能够在隔离的容器环境中作为"一等公民"平滑运行。这为云原生研发人员在纯软件定义的搭建环境中部署、调试以及验证复杂的容器化 RDMA 应用奠定了堅实的基础。