4. 测试环境搭建

RDMA性能测试的成败，往往在测试环境搭建阶段就已注定。一个设计不严谨的测试环境，轻则导致性能数据无法复现，重则掩盖真实的网络瓶颈，使调优工作失去方向。本章将系统拆解硬件选型、软件栈配置与网络拓扑设计三大核心环节，帮助您构建一个可信、可复现、可对比的RDMA基准测试平台。

4.1 硬件选型：网卡、交换机与线缆的匹配逻辑

核心原理：RDMA性能测试的硬件选型并非追求单一器件的最强性能，而是追求系统级匹配。网卡（HCA，Host Channel Adapter）决定了端点的收发能力，交换机决定了网络转发与拥塞控制能力，线缆与光模块则决定了物理层的信号完整性。三者必须形成闭环匹配，任何一环的短板都会成为性能天花板。例如，一台配备100Gb/s HCA的服务器，如果PCIe 3.0 x8通道仅提供约64Gb/s的理论带宽，那么实际测试中网卡将无法达到线速。

判断方法：选型时应遵循以下优先级顺序：

1. 明确测试目标速率：是验证25Gb/s、100Gb/s还是400Gb/s的RDMA性能？目标速率直接决定后续所有选型。
2. 检查服务器PCIe通道：使用 lspci -vvv 或 dmidecode 确认空闲PCIe插槽的通道数（x8或x16）与代数（3.0/4.0/5.0）。PCIe 4.0 x16可提供约256Gb/s单向带宽，足以支撑200Gb/s网卡。
3. 匹配网卡端口速率与交换机端口速率：若交换机仅支持25Gb/s端口，则100Gb/s网卡需使用4x25Gb/s链路聚合（Link Aggregation）或降速运行，这会引入额外延迟与配置复杂度。
4. 线缆类型选择：短距离（<3米）优先选择DAC（Direct Attach Cable）铜缆，成本低、功耗小；3-10米可选择AOC（Active Optical Cable）有源光缆；超过10米必须使用光模块+光纤。务必确认线缆两端接口类型（QSFP28、SFP56等）与网卡/交换机端口匹配。

4.2 软件栈配置：驱动、固件与OFED的版本协同

核心原理：RDMA软件栈由固件（Firmware）、内核驱动、用户态库（libibverbs、librdmacm）及测试工具（perftest）组成。固件运行在网卡内部，负责处理底层报文；驱动运行在内核空间，提供协议栈接口；OFED（OpenFabrics Enterprise Distribution）则是一套整合了驱动、库和工具的发行包。三者版本必须严格匹配，否则会出现API不兼容、性能异常甚至内核崩溃。

操作流程：搭建软件栈的推荐步骤如下：

# 1. 确认当前系统内核版本
uname -r

# 2. 下载并安装匹配的MLNX_OFED驱动
wget https://www.mellanox.com/downloads/ofed/MLNX_OFED-5.8-1.0.1.1/MLNX_OFED_LINUX-5.8-1.0.1.1-rhel8.6-x86_64.tgz
tar xzf MLNX_OFED_LINUX-5.8-1.0.1.1-rhel8.6-x86_64.tgz
cd MLNX_OFED_LINUX-5.8-1.0.1.1-rhel8.6-x86_64
./mlnxofedinstall --add-kernel-support

# 3. 验证驱动与固件版本
ibv_devinfo -v | grep -E "fw_ver|hca_id"
mlxup --query  # 查询固件版本

# 4. 确认OFED工具链可用
which ib_write_bw ib_read_bw ibv_rc_pingpong

案例拆解：某金融科技公司在搭建高频交易测试环境时，使用了ConnectX-5网卡与MLNX_OFED 4.9版本驱动。测试中发现 ib_write_bw 的延迟比预期高30%。排查过程如下：

• 首先检查固件版本，发现固件为16.25.1014，而OFED 4.9要求的最低固件版本为16.26.2008。
• 使用 mlxup 工具将固件升级至16.26.2008，延迟恢复正常。
• 进一步检查驱动参数，发现 num_of_vfs 被误设为8，导致网卡资源被虚拟化功能占用。修改为0后，延迟再降低5%。

4.3 网络拓扑设计：从直连到多级交换的权衡

核心原理：网络拓扑决定了数据路径的长度与拥塞点位置。对于性能测试而言，拓扑设计的目标是最小化变量。直连拓扑（两台服务器背靠背）消除了交换机的影响，适合验证网卡与协议栈的极限性能；单交换机拓扑引入了转发延迟与拥塞控制机制，更接近真实部署；多级交换拓扑（如胖树）则用于大规模集群测试，但需要关注哈希不均与PFC死锁问题。

判断方法：选择拓扑时应考虑以下因素：

• 测试目的：验证网卡极限性能选直连；验证交换机能力选单交换；验证大规模扩展性选多级。
• 端口数量：单台交换机端口数是否满足所有测试节点接入？若不足，需考虑多级或Spine-Leaf架构。
• 拥塞控制验证：若需测试PFC或ECN效果，必须使用交换机拓扑，并配置相应的QoS策略。

案例拆解：某云服务商在部署100Gb/s RoCEv2集群时，最初采用Spine-Leaf两级拓扑（4台Spine+8台Leaf）。在性能测试中发现，当多个Leaf节点同时向同一Spine端口发送数据时，吞吐量下降至60%。分析过程：

1. 使用 perfquery 检查交换机端口计数，发现Spine下行端口出现大量丢弃（Discard）计数。
2. 确认ECN标记未生效，因为交换机固件未开启 ecn_configure 参数。
3. 在Leaf交换机上启用ECN，并设置 threshold=50000（字节），同时开启PFC流控。
4. 重新测试，吞吐量恢复至95%以上，延迟抖动明显降低。

4.4 环境验证与基线建立

核心原理：测试环境搭建完成后，必须进行连通性与基线性能验证，确保环境本身不引入额外误差。基线数据（如 ib_write_bw 的带宽与延迟）是后续所有对比测试的参照系。

操作流程：

# 1. 连通性测试
ibping -S 12345 -C 1 -P 1   # 服务端
ibping -G 0x0002c9030000abcd -S 12345 -C 100 -P 1  # 客户端

# 2. 查询链路状态
ibstatus

# 3. 运行基线带宽测试（服务端）
ib_write_bw -d mlx5_0 -i 1 -s 1048576 -t 30 --report_gbits

# 4. 运行基线延迟测试（服务端）
ib_write_lat -d mlx5_0 -i 1 -s 16 -t 30

常见误区：

• 误区一：忽略PCIe NUMA节点。网卡插在CPU0的PCIe槽上，但测试进程运行在CPU1核心，导致跨NUMA访问，延迟增加20%以上。应使用 numactl --cpunodebind=0 绑定CPU。
• 误区二：未关闭防火墙或irqbalance。防火墙拦截RDMA报文，irqbalance频繁迁移中断，导致性能抖动。测试前应 systemctl stop firewalld 并 systemctl stop irqbalance。
• 误区三：使用默认MTU。RoCEv2建议设置MTU为4096（即 ip link set dev ib0 mtu 4096），默认1500会显著降低大包带宽。