必须用专用RDMA工具且服务端/客户端命令不可互换：ib_send_lat测2字节单向延迟为1.2–1.6μs，ib_write_bw（RC模式、大包、多QP）测极限带宽，qperf因走IPoIB和内核路径不适用极限测试。
直接测不准，必须用专用 RDMA 工具，且服务端/客户端命令不能反着写——否则延迟虚高、带宽掉一半以上。
ib_send_lat 测单向延迟：为什么 2 字节消息才真实
IB 网络的“极致延迟”只在极小包下成立，ib_send_lat 是唯一能逼近硬件层单向延迟的工具。它不走 TCP/IP 栈，绕过内核协议栈，直通 HCA（主机通道适配器）。
- 服务端只需运行
ib_send_lat -a -c UD -d mlx5_0 -i 1（-a启用忙等待，消除调度抖动） - 客户端执行
ib_send_lat -a -c UD -d mlx5_0 -i 1 10.10.10.2（IP 必须是服务端 IB 接口地址） - 结果里
2字节那行的Latency值才是参考基准，典型值在1.2–1.6 μs；别信 1024 字节以上的延迟，那已含传输开销 - 常见错误：用
ping或qperf ud_lat测——它们走的是 IPoIB 封装，多出至少 8–12 μs 的额外延迟
ib_write_bw 测单向带宽极限：RC 模式 + 大包 + 多 QP 才压得出峰值
ib_send_bw 虽常用，但本质是 Send/Recv 操作，有应答开销；真正打满物理带宽得用 ib_write_bw，它走纯 RDMA Write 协议，零 CPU 参与远程写入。
- 服务端：
ib_write_bw -a -c RC -d mlx5_0 -i 1 --report_gbits（-c RC关键，UD 模式带宽上限低 30%+） - 客户端：
ib_write_bw -a -c RC -d mlx5_0 -i 1 --report_gbits 10.10.10.2 - 要冲极限带宽，必须加参数：
-s 1048576（1MB 消息）、--run_infinitely（避免启动/结束抖动）、--qp 8（开 8 个 Queue Pair 并发） - 注意 MTU：若
ibstat显示Mtu : 2048，却用-s 4096，实测带宽会骤降 40%，因为触发分片重传
为什么 qperf 不适合测 IB 极限指标
qperf 方便，但它是通用型工具，底层仍依赖 socket API 和 IPoIB 驱动，无法绕过内核转发路径。
-
qperf 10.10.10.2 ud_lat测出来是 10–15 μs，不是 IB 硬件能力，是 IPoIB 封装+内核调度叠加的结果 -
qperf 10.10.10.2 rc_rdma_write_bw看似走 RDMA，但实际调用的是 librdmacm 抽象层，有连接建立开销和 buffer copy，比原生ib_write_bw低 15–25% - 它适合横向对比 TCP vs RDMA，不适合压测单卡单链路的物理极限
CPU 绑定与 NUMA 亲和性：最容易被忽略的瓶颈点
IB 网卡和内存不在同一 NUMA node 时，DMA 读写会跨 die，延迟翻倍、带宽掉 30% 以上。
- 先查绑定关系：
lscpu | grep "NUMA node"+mst status -v | grep -A5 mlx5_0 - 服务端启动前加
taskset -c 4-7，客户端加taskset -c 12-15，确保 CPU 核与网卡所属 NUMA node 一致 - 若用
--run_infinitely长时间跑，务必加-F（禁用频率调节），否则 CPU 自动降频会导致带宽波动超 ±20% - 别依赖默认
-i 1：在 400Gbps 卡上，-i 256才能让 QP 充分饱和；-i 1仅适合快速摸底
