补丁链接： 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 的底层传输机制存在“硬编码”限制：
全局 Socket 绑定： 在旧版本实现中，当 rdma_rxe 模块加载时，它会在初始网络命名空间 (init_net) 中创建一个 UDP Socket（监听 4791 端口）。
隔离障碍： 根据 Linux 内核的网络隔离原则，命名空间 A 里的进程无法直接使用命名空间 B 里的 Socket。
归属错误： 无论用户在哪个命名空间创建 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 现在可以完美支持以下三种复杂的网络拓扑：
网络命名空间与宿主机互联：容器可以直接与宿主机的物理网卡或虚拟网卡进行 RDMA 通信。
两个独立命名空间通过 veth pair 互联：模拟两个容器在同一台主机上通过虚拟线缆直接通信。
多个命名空间通过虚拟网桥 (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
