提到 RDMA 性能测试大多数人第一反应是需要 100G 交换机、ConnectX-5 网卡、物理服务器集群动辄几十万投入。但本文要展示的是一台普通笔记本电脑、两个 Ubuntu 虚拟机、零硬件成本同样能完成一套完整的 RDMA 参数调优实验并且得出与硬件环境截然不同的反直觉结论。我们在 Soft-RoCErxe虚拟化环境中系统性地扫描了消息大小、MTU、QP 数、Post List、CQ Moderation、CPU 绑核等六大类参数发现两个核心反直觉现象CQ Moderation 开大反而带宽暴跌 64%硬件环境建议开大以省 CPUtaskset 绑核反而性能下降 44%硬件环境绑核是标准优化手段这些反常背后指向一个关键认知Soft-RoCE 的软件栈架构与硬件 RDMA 完全不同盲目移植硬件调优经验不仅无效还可能适得其反。​1. 实验环境1.1 硬件与虚拟化平台项目配置宿主机笔记本电脑Intel Core i7-10xxx, 16GB RAM虚拟化软件VMware Workstation 17虚拟机 × 2Ubuntu 22.04, 内核 5.15.0-xx, 4 vCPU, 8GB 内存RDMA 实现Soft-RoCE (rdma_rxe)设备名 rxe_0网络互联VMware 虚拟网桥VMnet两台 VM 同网段互通以太网 MTU9000Jumbo Frame两端均已配置RDMA MTUactive_mtu 4096测试工具perftest 4.5-0.18, rdma-core 39.01.2 环境声明本文实验环境为笔记本电脑虚拟化平台两台 Ubuntu VM 通过宿主机虚拟网桥互联RDMA 传输由 Soft-RoCErxe在 CPU 上软件模拟实现。数据路径不经过物理网卡而是在宿主机内存中通过虚拟交换机完成 VM 间转发因此绝对带宽数值远低于物理机 硬件 RDMA 网卡的表现。本文定位为参数敏感性验证关注不同配置下带宽的相对变化趋势而非提供线速基准数据。所有带宽数据取 ib_write_bw 输出的BW average​ 值总数据量/总耗时代表稳态吞吐。1.3 测试命令规范全文统一使用 ib_write_bw服务端ib_write_bw -d rxe_0 -i 1 -x 2 [参数...]客户端ib_write_bw -d rxe_0 -i 1 -x 2 [参数...] server_ip-x 2 指定 GID indexRoCEv2 / IPv4两端均需配置一致。2. 基线消息大小对带宽的影响2.1 测试方法固定参数MTU4096, QP1, post_list1消息大小从 64B 到 1MB 扫描。for size in 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576; doecho size$size ib_write_bw -d rxe_0 -s $size -m 4096 -q 1 -l 1 -x 2 --report-gbits server_ip 21 | tail -3done2.2 实测结果消息大小带宽 (Gb/s)备注64B0.021小消息协议头主导512B0.0854KB0.66拐点附近16KB2.1964KB2.50本环境带宽峰值区256KB2.381MB0.77大消息开销显现2.3 分析在 Soft-RoCE 环境下小消息带宽极低64B 消息带宽仅 0.021 Gb/s每次 ibv_post_send 要走完 rxe 内核模块 → UDP 封装 → 虚拟交换机 → 对端解包的全路径CPU 开销远大于有效载荷。4KB 附近出现拐点与 MTU4096 的分片边界吻合超过此值后单消息需拆多个包封装开销叠加。64KB 以上带宽趋于饱和瓶颈固定在 CPU 处理能力虚拟交换机转发 rxe 软栈增大消息大小不再提升带宽1MB 时反而因内存拷贝开销下降。3. 网络层参数MTU 的影响3.1 测试设计固定QP1, 消息大小64KB扫描 MTU。for mtu in 512 1024 2048 4096; doecho mtu$mtu ib_write_bw -d rxe_0 -s 65536 -m $mtu -q 1 -x 2 --report-gbits server_ip 21 | tail -3done3.2 实测结果MTU带宽 (Gb/s)相对 1024 提升5120.28-30%10240.40基准20480.92130%40961.16190%3.3 分析MTU 从 1024 提到 4096带宽提升近3 倍在 Soft-RoCE 下效果比硬件环境更显著协议头开销占比更大每个包固定封装约 58B以太网头 IP UDP RoCE ICRC小 MTU 下有效载荷率极低CPU 中断频率降低大消息拆包数减少每包触发一次处理减少 CPU 总工作量4. 队列层参数QP 数与 Post List Size4.1 QP 数扫描for qp in 1 2 4 8; doecho qp$qp ib_write_bw -d rxe_0 -s 65536 -m 4096 -q $qp -x 2 --report-gbits server_ip 21 | tail -3doneQP 数聚合带宽 (Gb/s)备注11.11基准22.7543.6483.37锁竞争导致回落分析Soft-RoCE 是单线程软实现多 QP 不能并行利用多网卡队列反而增加 rxe 内核模块内部锁竞争。QP4 达到最优QP8 开始回落。4.2 Post List Size一次投递 WR 数量for pl in 1 4 8 16 32; doecho post_list$pl ib_write_bw -d rxe_0 -s 65536 -m 4096 -q 1 -l $pl -x 2 --report-gbits server_ip 21 | tail -3donePost List (-l)带宽 (Gb/s)说明11.12每次投递 1 个 WR41.5081.53162.45322.46边际递减分析增大 post_list-l 参数减少 ibv_post_send 调用次数降低用户态/内核态切换频率。在 CPU 瓶颈环境下效果明显从 1 到 16 提升约119%。⚠️避坑perftest 中控制一次投递 WR 数量的是 -l--post_list不是 -b。-b 是 bidirectional 双向模式不带参数。5. 完成语义层Inline 与 CQ Moderation5.1 Inline DataInline 对 ib_write_bw 带宽测试影响有限。在 Soft-RoCE 环境下大消息 inline 无效超过 max_inline_data 限制小消息带宽本身极低inline 带来的微小改善被协议栈开销淹没。# 验证可选ib_write_bw -d rxe_0 -s 64 -m 4096 -I 64 -q 1 -x 2 --report-gbits server_ip结论带宽测试中 inline 不是关键变量生产环境如需优化延迟再单独测试。5.2 CQ ModerationSoft-RoCE 下的反直觉现象测试命令for mod in 1 4 8 16 32; doecho cq_mod$mod ib_write_bw -d rxe_0 -s 65536 -m 4096 -q 2 --cq-mod$mod -x 2 --report-gbits server_ip 21 | tail -3done实测结果CQ Mod带宽 (Gb/s)相对 cq-mod115.11基准44.96-3%84.71-8%161.84-64%​321.17-77%​反直觉分析查阅 RDMA 技术文档硬件环境下的常规建议是适当增大 CQ Moderation减少 CQE 数量和 CPU 中断频率带宽基本不受影响甚至略有提升。但本次实测完全相反。--cq-modN 的含义是每 N 个 WR 完成才生成一个 CQE。perftest 的发送循环依赖 CQE 来补充新 WQEpost WQE → 等 CQE → poll 完成 → 补充新 WQE → 继续 post硬件 RDMA网卡有独立 DMA 引擎CQE 只是通知不影响发送节奏。cq-mod 大 → CQE 少 → CPU 省 → 带宽持平。Soft-RoCE发送和完成上报全靠 CPU 内核线程。cq-mod 大 → CQE 稀疏 → 应用迟迟不补 WQE → 管道里在途请求变少 → 带宽暴跌。cq-mod16 时等待期间 vCPU 被调度走或进入空闲恢复后 QP 已空需要重新填充带宽自然崩。结论Soft-RoCE 下 cq-mod1默认最有利于维持发送流水线饱满不宜盲目套用硬件调优经验。6. 系统层绑核与 Hugepage6.1 taskset 绑核又一个反直觉测试命令# 不绑核默认ib_write_bw -d rxe_0 -s 65536 -m 4096 -q 2 -x 2 --report-gbits server_ip# 绑核taskset -c 0,1 ib_write_bw -d rxe_0 -s 65536 -m 4096 -q 2 -x 2 --report-gbits server_ip实测结果配置带宽 (Gb/s)相对变化不绑核默认调度3.00基准taskset -c 0,1 绑核1.69-44%​分析绑核后性能下降 44%与硬件 RDMA 环境的常见结论相反。原因Soft-RoCE 是多内核线程协作模型ibv_post_send 触发的内核 rxe 模块、虚拟网卡驱动、软中断处理ksoftirqd分散在不同内核线程中。绑核造成资源争抢将用户态测试进程钉在 CPU 0-1 后内核线程也被调度到同一组核上用户态与内核态处理互相抢占 CPU 时间片。OS 调度器的默认策略反而更优不绑核时调度器将用户态进程与内核线程分散到不同 vCPU减少互相阻塞。启示硬件 RDMA 绑核有效是因为真正的 I/O 由网卡 DMA 完成不消耗 CPUSoft-RoCE 下所有工作都在 CPU 上绑核反而限制了调度器的灵活性。6.2 Hugepageperftest 默认使用 4KB 页。Soft-RoCE 环境下 hugepage 对带宽影响有限瓶颈在 CPU 软栈而非 TLB生产环境建议配置cat /proc/meminfo | grep Hugesudo sysctl vm.nr_hugepages2567. 综合最优配置 vs 默认配置7.1 默认配置ib_write_bw -d rxe_0 -s 65536 -x 2 server_ip结果带宽2.54 Gb/s7.2 调优配置ib_write_bw -d rxe_0 -s 65536 -q 4 -m 4096 -l 32 -x 2 --cq-mod4 --report-gbits 192.168.95.128结果带宽4.98 Gb/s7.3 对比总结指标默认配置调优配置提升幅度带宽2.54 Gb/s4.98 Gb/s96%​核心发现MTU Post List QP 数​ 是 Soft-RoCE 环境下性价比最高的三个调优手段CQ Moderation 不宜开大cq-mod1 最优开到 16 带宽暴跌 64%绑核有害不绑核比绑核快 78%多 QP 有甜区QP4 最优QP8 开始回落所有优化叠加后带宽接近翻倍96%说明参数组合 单参数极致8. 结论Soft-RoCE 虚拟化环境适合做 RDMA 参数学习和带宽趋势验证不适合做绝对性能评价。CPU 软栈为瓶颈的环境下减少 CPU 工作量的参数MTU↑、post_list↑、QP 适度↑收益最大。硬件 RDMA 的调优经验不能直接移植到 Soft-RoCE本文两个反直觉现象CQ Moderation 开大暴跌、绑核反降 44%共同证明Soft-RoCE 是一个完全不同的性能模型。本文所有测试可在普通笔记本电脑上复现适合作为高校 RDMA 实训课程的教学案例尤其适合讲解环境差异导致优化方向不同这一核心概念。附录 A环境搭建速查# 1. 安装依赖sudo apt install -y rdma-core ibverbs-utils perftest iproute2# 2. 加载模块sudo modprobe rdma_rxe# 3. 创建 Soft-RoCE 设备假设接口为 ens33sudo rdma link add rxe_0 type rxe netdev ens33# 4. 修改以太网 MTUsudo ip link set dev ens33 mtu 9000# 5. 验证rdma linkibv_devinfo -d rxe_0 | grep -i mtushow_gids# 6. 启动测试# 服务端ib_write_bw -d rxe_0 -m 4096 -x 2# 客户端ib_write_bw -d rxe_0 -m 4096 -x 2 server_ip附录 B常见故障排查问题原因解决IB device wasnt found设备名错或 rxe 未创建rdma link 确认名字modprobe rdma_rxeRequested mtu is higher than active mtu以太网口 MTU 未改ip link set dev iface mtu 9000能 ping 但 ib_write_bw 不通GID index 不对show_gids 找 IPv4 行用 -x 指定带宽只有几百 Kb/s防火墙拦了 UDP/4791sudo ufw disable 或放行 4791Device or resource busy端口被占用换 -i 2 或杀残留进程Invalid Command line参数写错如 -b 带数字-b 是双向模式不带参数burst 用 -linline 用 -I附录 Cperftest 易混参数速查目的参数易混点消息大小-sIB/RoCE MTU-mQP 数-qGID index-x带宽按 Gbps--report-gbitsInline 最大长度-I不是 -l一次投递 WR 数-l不是 -b双向带宽-b不带数字CQ Moderation--cq-mod双横线不是 -c持续时长(秒)-D迭代次数-n作者注本文所有测试在个人笔记本电脑虚拟化环境中完成数据仅反映该环境下的相对趋势。如需引用绝对性能数据请以物理硬件测试为准。