如何验证容器内 RDMA 带宽与裸机一致 - 问题详情 - 创脉思

解读

在国内金融、AI 训练、运营商 NFV 等生产环境，RDMA 已成为 100 Gbps 以上低延迟场景标配。面试官问“容器内 RDMA 带宽能否打平裸机”，核心想确认三件事：

你是否真的在 宿主机上开启并绑定了 RDMA 设备（RoCE v2 或 InfiniBand），而不是只跑了 TCP 回退；
容器是否通过 --device 或 SR-IOV VF 拿到了独占的 RDMA 字符设备，且 rdma 子系统 cgroups 未做带宽限制；
你是否会用 国内机房常用的 perftest 套件（由阿里云/腾讯云/华为云镜像源提供）做双端打流，并排除 NUMA、PCIe 卡位、驱动版本、QoS 等干扰。

答不到“如何排除虚拟化开销”和“如何固定 NUMA 节点”，基本会被判“只背过命令，没上过 100G 网卡”。

知识点

RDMA 设备模型：mlx5_0 等字符设备、uverbs 接口、SR-IOV PF/VF、RoCE v2 的 DSCP/ECN 流控；
Docker 设备透传：--device /dev/infiniband/uverbs0、--device /dev/infiniband/rdma_cm、libmlx5 库挂载；
cgroup v1/v2 rdma 控制器：max_rd_atomic、max_mw、hca_handle 限制，默认无上限但需检查 /sys/fs/cgroup/rdma；
性能基准：perftest 里的 ib_write_bw、ib_read_bw、ib_send_bw，国内习惯跑 60 s、QP=1、消息 4 M、--report_gbits；
干扰因素：NUMA 距离、PCIe 3.0 vs 4.0、LLC 竞争、宿主机 irqbalance、网卡固件 MLNX_OFED 5.8+、Docker bridge 未禁用；
合规要求：等保 2.0 对裸金属与容器“同库同表”审计，带宽一致是性能基线验收项，需留档截图。

答案

前置检查
a. 宿主机 lspci | grep Mellanox，确认固件版本 >= 20.32.1010；
b. ofed_info -s 确认 MLNX_OFED 驱动与容器内一致；
c. 查看 rdma 链路速率：cat /sys/class/infiniband/mlx5_0/ports/1/rate，应为 100 Gb/sec；
d. 关闭宿主机 irqbalance，把网卡中断绑到同一 NUMA node：
echo 2 > /proc/irq/24/smp_affinity_list

容器启动参数

docker run -it --rm --name rdma-test \
  --device /dev/infiniband/uverbs0 \
  --device /dev/infiniband/rdma_cm \
  --cap-add IPC_LOCK \
  --ulimit memlock=-1:-1 \
  --security-opt apparmor=unconfined \
  -v /sys/class:/sys/class:ro \
  -e RDMAV_FORK_SAFE=1 \
  registry.cn-hangzhou.aliyuncs.com/yourrepo/perftest:5.8

关键点：必须加 IPC_LOCK 与 memlock=-1，否则注册内存失败，带宽直接掉 30%。

打流脚本（两端容器同镜像）
Server 端：
ib_write_bw -d mlx5_0 -F --report_gbits -a -q 1 -t 60
Client 端：
ib_write_bw -d mlx5_0 -F --report_gbits -a -q 1 -t 60 <server_container_ip>
结果判读
- 裸机基线：同一机型、同一交换机端口，平均 97.3 Gb/s、CPU 占用 5%；
- 容器内跑三次取中位数，若 >= 97 Gb/s 且抖动 < 0.5 Gb/s，即判定“一致”；
- 若低于 95 Gb/s，立即检查：
  – perf top 看是否陷入 copy_user_enhanced_fast_string（缺页过多）；
  – cat /proc/interrupts 看是否跨 NUMA；
  – tc -s qdisc show 确认无 docker0 限速。
交付物
把 ib_write_bw 输出截图、numactl --hardware 拓扑、容器启动命令、对比表格写入 《RDMA 性能验收报告》，签字后随版本入库，满足国内甲方审计要求。

拓展思考

多容器共享同一 PF：可用 SR-IOV 将 PF 切成 8 个 VF，通过 --device /dev/infiniband/mlx5_0d1 透传给不同容器，再用 ib_write_bw -d mlx5_0d1 验证隔离后带宽是否仍达 12.5 GB/s；
Kubernetes 场景：用 RDMA Device Plugin 把 VF 以 resource 形式暴露，request 资源后走 Macvlan + SR-IOV CNI，同样跑 perftest，确认 Pod 迁移前后带宽零损耗；
RoCE v2 流控：国内云厂商 TOR 交换机常开 PFC + ECN，若容器内带宽掉 10%，优先在交换机侧调 DSCP 26 的 buffer 门限，而非盲目升级驱动；
安全加固：最小镜像里删掉 sshd、用非 root 用户跑 perftest，需加 cap_sys_rawio 能力，证明“安全与性能可兼得”；
国产化替代：华为昇腾 910B + HCCS RDMA，容器内使用 hccn_tool 替代 ibstat，思路完全一致，带宽验收门槛提到 200 Gb/s。