补丁链接： linux-rdma patch series

---

一、 背景与问题：为什么 RXE 不能在容器中正常工作？

随着云原生技术的发展，Docker 和 Kubernetes 等容器技术广泛应用。容器的核心基础之一是 Linux 网络命名空间 (Network Namespace)，它实现了网络堆栈的隔离，让每个容器拥有独立的 IP、路由表和端口空间。

然而，长期以来 Soft-RoCE (RXE) 驱动在网络命名空间中存在一个致命问题：无法正常通信。

现象：

当我们在一个非初始命名空间（例如 Docker 容器内部）尝试创建一个 RXE 设备：

ip netns exec container0 rdma link add rxe0 type rxe netdev eth0

虽然设备看似创建成功，但实际无法完成任何 RDMA 传输。

---

二、 深度分析：问题的根源

通过深入内核源码分析，我们发现 RXE 的底层传输机制存在“硬编码”限制：

1. 全局 Socket 绑定： 在旧版本实现中，当 rdma_rxe 模块加载时，它会在初始网络命名空间 (init_net) 中创建一个 UDP Socket（监听 4791 端口）。

2. 隔离障碍： 根据 Linux 内核的网络隔离原则，命名空间 A 里的进程无法直接使用命名空间 B 里的 Socket。

3. 归属错误： 无论用户在哪个命名空间创建 RXE 链路，其底层的 UDP 传输路径始终指向宿主机的 init_net。这导致容器内的 RDMA 流量在寻找 UDP 端口时，如同进入了一个不存在的死胡同。

---

三、 解决方案与实现方案

为了支持网络命名空间，朱彦军 (Zhu Yanjun) 提交的系列补丁对 RXE 的资源管理进行了重构，核心思路是**“从全局管理转为局部管理”**。

1. 实现 Per-Net Namespace 管理

引入了 pernet_operations 机制。这意味着 RXE 驱动现在能够感知不同的命名空间。每个命名空间现在都会拥有自己独立的 RXE 运行上下文。

2. 动态创建 UDP Socket

改变了 Socket 的创建时机：

• 不再在模块加载时全局创建。

• 改为在特定的命名空间内，当用户执行 rdma link add 时，才在该空间内动态创建对应的 IPv4/IPv6 UDP Socket。

• 当 rdma link del 删除链路时，自动销毁对应的 Socket。

3. 命名空间感知的数据包处理

重构了接收和发送路径，确保数据包在处理时能够正确关联到其所属命名空间的网络堆栈。

---

四、 典型应用场景

通过该改进，RXE 现在可以完美支持以下三种复杂的网络拓扑：

1. 网络命名空间与宿主机互联：容器可以直接与宿主机的物理网卡或虚拟网卡进行 RDMA 通信。

2. 两个独立命名空间通过 veth pair 互联：模拟两个容器在同一台主机上通过虚拟线缆直接通信。

3. 多个命名空间通过虚拟网桥 (Bridge) 互联：模拟标准 Docker 网络模型，多个容器连接到同一个虚拟交换机。

---

五、 测试验证：4 个关键步骤

您可以按照以下步骤验证修复后的 RXE 功能：

1. 拓扑准备（以两个命名空间为例）

将网卡分配到不同的空间：

# net0 拥有 eno2, net1 拥有 eno3
ip netns exec net0 ip link set eno2 up
ip netns exec net1 ip link set eno3 up

2. 在各自命名空间添加 RDMA 链路

# net0 空间
ip netns exec net0 rdma link add rxe0 type rxe netdev eno2
# net1 空间
ip netns exec net1 rdma link add rxe1 type rxe netdev eno3

3. 运行 rping 通信测试

验证跨命名空间的连通性：

# 服务端 (net0)
ip netns exec net0 rping -s -a 192.168.2.1 -C 1 &
# 客户端 (net1)
ip netns exec net1 rping -c -a 192.168.2.1 -d -v -C 1

如果看到 ping data: rdma-ping-0: ABC...，说明通信成功！

4. 资源清理与 Socket 状态检查

验证 Socket 是否随链路销毁而释放：

# 查看端口监听
ip netns exec net0 ss -lu  # 应显示监听 4791
# 删除链路
ip netns exec net0 rdma link del rxe0
# 再次查看
ip netns exec net0 ss -lu  # 4791 端口应已自动关闭

---

总结

通过将 RXE 驱动改为命名空间感知 (Namespace-aware)，我们解决了 Soft-RoCE 在容器化环境下的部署难题。这为高性能计算 (HPC) 在云环境中的虚拟化和隔离提供了更灵活的选择。

更多技术细节，请参考补丁详情：Zhu Yanjun - RXE NetNS Support

如上图所示，已经合入linux kernel mainline