拓冰网站定制 
简介这是一份面向网络与系统方向工程师、高性能计算及数据中心从业者的RDMA技术调研文档适合希望系统理解远程直接内存访问原理、协议选型与编程接口的初中级读者。内容围绕零拷贝、内核旁路与CPU卸载三大核心优势展开梳理Infiniband、RoCE、iWARP三种协议的差异与适用场景并讲解WQ、SQ、RQ、CQ、QP等关键术语及SEND/RECV、WRITE/READ、ATOMIC等通信操作同时介绍verbs与rdma-core两种编程路径可帮助读者建立从概念到落地的完整认知框架。资源包共1个PDF文件约1.01MB篇幅紧凑、结构清晰便于按章节检索与快速通读。目前已有528人学习下载适合作为RDMA入门调研与方案选型的参考材料。1. RDMA 技术调研一份 PDF 背后到底藏着哪些工程决策第一次认真翻 RDMA 技术调研类 PDF 的人多半是被同一类问题逼过来的训练集群里 GPU 利用率上不去分布式存储的尾延迟忽高忽低或者跨节点 RPC 的 CPU 占用高得离谱。标题写的是「RDMA 技术调研」但真正要回答的其实是——在我的场景里RDMA 到底值不值得上上了之后怎么配、怎么测、怎么排错。这份调研不是让你背协议栈而是帮你把 RoCEv2、InfiniBand、iWARP 三条路线、Verbs 编程模型、以及 PFC/ECN 这套拥塞控制组合拳落到一张能拍板的选型表上。适合正在做 AI 训练网络、分布式存储、高频交易中间件的工程师也适合被「无损网络」四个字忽悠过、想搞清楚代价的人。下面按「先立住概念 → 再动手跑通 → 最后避坑」的顺序展开能抄的命令和参数我都给全。2. 三条技术路线怎么选RoCEv2、InfiniBand 与 iWARP 的取舍RDMA 的核心承诺只有一句话让网卡直接读写远端内存绕过内核协议栈和 CPU 拷贝。但「怎么绕过」在不同路线里差别巨大选错路线后面全是坑。2.1 三种 RDMA 实现的本质差异InfiniBand 是原生方案从链路层到传输层整套自研天生支持无损和拥塞控制性能最稳代价是专用交换机和 HCA 卡生态相对封闭。RoCEv2 把 IB 的传输层架在 UDP/IP 之上能跑在标准以太网交换机上是当下数据中心最主流的选择但它把「无损」这件事交给了以太网的 PFC 和 ECN 去兜底配置复杂度陡增。iWARP 把 RDMA 架在 TCP 之上兼容性最好、对网络设备要求最低但 TCP 的重传和拥塞控制会拖累延迟实际部署远少于前两者。一句话选型追求极致稳定和低延迟、预算充足选 InfiniBand要在现有以太网上做大规模部署、能接受调优成本选 RoCEv2只在特定兼容场景下才考虑 iWARP。2.2 用 ibv_devinfo 和 perftest 确认硬件与链路能力选型之前先摸清手里有什么卡、什么链路。装好 OFED 或发行版自带的 rdma-core 后第一件事是确认设备状态。# 查看本机所有 RDMA 设备及其端口状态 ibv_devinfo -v # 关注输出里的几个关键字段 # state: PORT_ACTIVE - 端口已激活可以通信 # link_layer: Ethernet - 说明是 RoCEInfiniBand 会显示 InfiniBand # active_speed: 100.0 Gbps - 实际协商速率和标称不符要查线缆/光模块 # active_width: 4X - 链路宽度state不是PORT_ACTIVE时先别急着写代码八成是链路或驱动问题。link_layer直接决定你后面走 RoCE 还是 IB 的配置路径这个字段看错后面 PFC 配置全白做。确认链路后用 perftest 套件做裸带宽和延迟基线这是判断「值不值得上」的第一手数据。# 服务端监听等待客户端连接 ib_write_bw -d mlx5_0 -a -F --report_gbits # 客户端连接服务端 IP跑 10 秒带宽测试 ib_write_bw -d mlx5_0 -a -F --report_gbits 192.168.1.10 # 延迟测试换成 ib_write_lat参数含义一致 ib_write_lat -d mlx5_0 -F 192.168.1.10-d指定设备名-a跑所有消息尺寸-F允许在不同 CPU 上跑避免绑核干扰--report_gbits让结果以 Gb/s 显示。带宽测试看大消息1MB 以上能否打满链路延迟测试看小消息2 字节到 64 字节的往返时间。如果 100G 链路只跑出 30G先查 PCIe 带宽和 NUMA 绑定别怀疑网卡。2.3 RoCEv2 无损网络的两个必调开关PFC 与 ECNRoCEv2 最大的坑在于它假设网络无损但以太网默认会丢包。丢包一旦发生RDMA 的重传代价极高性能断崖式下跌。所以必须配 PFC优先级流控和 ECN显式拥塞通知。PFC 的作用是当某个优先级的队列快满时向上游发暂停帧让上游先别发。配置要点是给 RDMA 流量打上特定 DSCP 优先级常见是 3 或 4在交换机所有端口上为这个优先级开启 PFC。ECN 则是在拥塞初期就标记数据包让接收端通知发送端降速避免走到 PFC 触发暂停那一步。# 在主机侧为 RoCE 流量设置 DSCP 优先级以优先级 3 为例 # 先看网卡是否支持 trust dscp mlnx_qos -i ens1f0 # 把 RoCE 流量映射到 TC3并开启 PFC mlnx_qos -i ens1f0 --trust dscp --pfc 0,0,0,1,0,0,0,0 # 查看当前 PFC 和优先级映射状态 mlnx_qos -i ens1f0 -s--pfc 0,0,0,1,0,0,0,0表示只对优先级 3 开启 PFC其余关闭。全开 PFC 会引发死锁和广播风暴这是血泪经验。交换机侧必须做同样的优先级映射两端不一致等于没配。ECN 的阈值设置更玄学一般从交换机端口的 30% 队列深度开始调太低会误标记导致降速太高则起不到预防作用。3. Verbs 编程模型从注册内存到完成队列的最小闭环搞清路线后真正写代码时面对的是 Verbs API。它的心智模型和 socket 完全不同第一次接触容易懵。3.1 QP、CQ、MR 三个核心对象的关系RDMA 通信的基本单位是 Queue PairQP分发送队列和接收队列。每个 QP 绑定一个 Completion QueueCQ操作完成后产生 Completion Queue EntryCQE。内存必须先注册成 Memory RegionMR拿到 lkey/rkey 才能被网卡直接访问。这套设计的目的是所有资源提前建好数据路径上零系统调用。一次典型的双边操作流程是注册 MR → 创建 CQ → 创建 QP → 交换 QP 信息通过带外通道→ 修改 QP 状态到 RTS → 提交发送/接收请求 → 轮询 CQ 拿完成事件。单边操作RDMA Read/Write不需要远端 CPU 参与但要求提前交换 rkey 和远端地址。3.2 一个可运行的双边发送最小示例下面这段代码展示发送端核心逻辑省略了连接建立和 QP 状态迁移的样板代码重点看资源创建和数据路径。#include infiniband/verbs.h // 1. 注册内存区域拿到 lkey struct ibv_mr *mr ibv_reg_mr(pd, buf, BUF_SIZE, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ); // IBV_ACCESS_LOCAL_WRITE 允许本端网卡写入这块内存 // REMOTE_WRITE/READ 允许远端通过 rkey 直接访问单边操作必须加 // 2. 创建 CQ容量 16 表示最多容纳 16 个未处理的完成事件 struct ibv_cq *cq ibv_create_cq(ctx, 16, NULL, NULL, 0); // 3. 创建 QPsend_cq 和 recv_cq 可以指向同一个 CQ struct ibv_qp_init_attr qp_attr { .send_cq cq, .recv_cq cq, .qp_type IBV_QPT_RC, // RC Reliable Connection最常用 .cap { .max_send_wr 16, .max_recv_wr 16, .max_send_sge 1, .max_recv_sge 1 } }; struct ibv_qp *qp ibv_create_qp(pd, qp_attr); // 4. 提交发送请求 struct ibv_sge sge { .addr (uintptr_t)buf, .length MSG_SIZE, .lkey mr-lkey }; struct ibv_send_wr wr { .wr_id 1, .sg_list sge, .num_sge 1, .opcode IBV_WR_SEND, .send_flags IBV_SEND_SIGNALED // 只有带 SIGNALED 才会产生 CQE }; struct ibv_send_wr *bad_wr; ibv_post_send(qp, wr, bad_wr); // 5. 轮询 CQ 等待完成 struct ibv_wc wc; while (ibv_poll_cq(cq, 1, wc) 0) { /* 忙等生产环境可加退避 */ } if (wc.status ! IBV_WC_SUCCESS) { // wc.status 是排错第一现场常见值 // IBV_WC_RNR_RETRY_EXC_ERR - 接收端没及时 post recv // IBV_WC_RETRY_EXC_ERR - 链路或对端 QP 异常 // IBV_WC_LOC_PROT_ERR - lkey 或权限不对 }关键参数说明IBV_QPT_RC是可靠连接保证不丢不乱序代价是需要维护连接状态IBV_SEND_SIGNALED决定是否产生完成事件批量发送时只给最后一个 WR 加 SIGNALED 能显著降低 CQ 压力这是性能优化的常见手法max_send_wr设太小会在高并发时 post 失败设太大浪费内存一般按峰值在途请求数的 1.5 倍估。3.3 单边操作与双边操作的性能分水岭双边 SEND/RECV 需要接收端提前 post recv两端 CPU 都参与。单边 WRITE/READ 只要求接收端提前注册好 MR 并告知 rkey数据路径上接收端 CPU 完全不参与。做分布式存储的数据落盘、AI 训练的梯度同步优先用单边 WRITE能把对端 CPU 从数据搬运里彻底解放出来。但单边操作没有天然的完成通知接收端要么轮询标志位要么用带立即数的 WRITE 触发一个 CQE这是设计时要提前想清楚的。4. 性能调优与验证把带宽和延迟压到硬件极限代码跑通只是及格线真正拉开差距的是调优。这一章讲怎么把 RDMA 的性能榨干以及怎么验证调优是否生效。4.1 用 perftest 做多维度基线测试单条 QP 往往打不满链路因为单个 QP 的吞吐受限于 PCIe 通道和网卡队列深度。要测出硬件极限得用多 QP 并发。# 服务端启动 8 个 QP 的带宽测试 ib_write_bw -d mlx5_0 -q 8 -a -F --report_gbits # 客户端对应连接 ib_write_bw -d mlx5_0 -q 8 -a -F --report_gbits 192.168.1.10 # 测试不同消息尺寸下的表现重点看这几个点 # 2B / 64B - 延迟敏感型看 ib_write_lat # 4KB - 典型 RPC 消息 # 1MB - 大块传输看能否打满-q 8表示用 8 个 QP 并发。如果单 QP 只有 40G、8 QP 能到 95G说明瓶颈在单 QP 的队列深度或 PCIe不在链路。这时可以考虑增大max_send_wr、开启多队列或者用 SR-IOV 虚拟化多张逻辑网卡。4.2 绑核、NUMA 与 PCIe 拓扑的隐形影响RDMA 性能对 CPU 和内存位置极其敏感。网卡插在 CPU0 的 PCIe 槽内存却分配在 CPU1 的 NUMA 节点跨节点访问会让带宽直接腰斩。# 查看网卡挂在哪颗 CPU 下 cat /sys/class/net/ens1f0/device/numa_node # 查看网卡 PCIe 链路速率和宽度 lspci -vv -s $(ethtool -i ens1f0 | grep bus-info | awk {print $2}) | grep -E LnkCap|LnkSta # 跑测试时把进程绑到网卡同侧 CPU numactl --cpunodebind0 --membind0 ib_write_bw -d mlx5_0 -a -FLnkSta显示的实际速率如果低于LnkCap说明 PCIe 降速了常见原因是插槽电气规格不够或 BIOS 里 PCIe 速率被限制。numactl绑核绑内存是必做项不绑的话测试结果波动能到 30% 以上这种玄学问题排查起来最费时间。4.3 用 ibv_rc_pingpong 快速验证连通性正式压测前先用 pingpong 确认两端 QP 能正常握手比直接上 perftest 更容易定位问题。# 服务端 ibv_rc_pingpong -d mlx5_0 -g 3 # 客户端-g 3 表示用 gid index 3RoCEv2 通常对应这个 ibv_rc_pingpong -d mlx5_0 -g 3 192.168.1.10-g指定 GID 索引RoCEv2 的 IPv4 映射 GID 一般在 index 3 附近用show_gids命令确认。如果 pingpong 不通但ibv_devinfo显示端口正常八成是 GID 索引选错或防火墙挡了 UDP 4791 端口。5. 避坑与排查RDMA 部署中最容易翻车的五件事这一章全是踩过的坑按「现象 → 原因 → 解决」写遇到问题直接对号入座。坑一PFC 全优先级开启导致网络死锁。现象是配置完 PFC 后整个网络间歇性卡死所有流量都受影响。原因是 PFC 对全部优先级生效一旦某个优先级拥塞触发暂停帧暂停帧本身也可能被阻塞形成循环等待。解决是只对 RDMA 流量所在的单一优先级开启 PFC其余优先级保持关闭并在交换机侧严格对齐。坑二ECN 阈值设太低带宽反而下降。现象是开了 ECN 后吞吐不升反降CQE 里频繁出现重传。原因是 ECN 标记阈值过低轻微拥塞就被标记发送端频繁降速。解决是把阈值从队列深度的 30% 起步逐步上调同时观察交换机端口的 ECN 标记计数标记率超过 10% 就说明阈值偏低。坑三MR 注册时权限给少了单边操作报 LOC_PROT_ERR。现象是 RDMA WRITE 提交后 CQE 返回IBV_WC_LOC_PROT_ERR。原因是注册 MR 时没加IBV_ACCESS_REMOTE_WRITE或者 lkey 传错。解决是单边操作必须同时加 LOCAL_WRITE 和 REMOTE_WRITE且发送端用的 lkey 必须来自同一块 MR。坑四接收端 recv 队列耗尽报 RNR_RETRY_EXC_ERR。现象是双边通信跑一段时间后连接断开CQE 显示 RNR 重试超限。原因是接收端 post recv 的速度跟不上发送端接收队列空了。解决是接收端提前批量 post 足够多的 recv WR或者改用单边 WRITE 彻底绕开这个问题。坑五跨 NUMA 跑测试性能数据完全不可信。现象是同样的配置两次测试带宽差一倍。原因是进程和内存没绑到网卡同侧 NUMA 节点。解决是所有性能测试和实际部署都用numactl绑核绑内存并把这条写进部署脚本别靠人记。6. 进阶技巧用 RDMA CM 管理连接与一个压测脚本模板手写 QP 状态迁移和带外交换 QP 信息很繁琐生产环境一般用 RDMA CMConnection Manager来管理连接生命周期。它把地址解析、路由解析、连接建立都封装成事件回调代码量能少一半。// RDMA CM 事件循环的核心骨架 struct rdma_event_channel *ec rdma_create_event_channel(); struct rdma_cm_id *id; rdma_create_id(ec, id, NULL, RDMA_PS_TCP); // 服务端绑定地址并监听 rdma_bind_addr(id, (struct sockaddr *)addr); rdma_listen(id, 8); // 事件循环处理连接请求、建立、断开 struct rdma_cm_event *event; while (rdma_get_cm_event(ec, event) 0) { switch (event-event) { case RDMA_CM_EVENT_CONNECT_REQUEST: // 对端发起连接在这里创建 QP 并 accept break; case RDMA_CM_EVENT_ESTABLISHED: // 连接就绪可以开始收发 break; case RDMA_CM_EVENT_DISCONNECTED: // 对端断开清理资源 break; } rdma_ack_cm_event(event); }RDMA_CM_EVENT_CONNECT_REQUEST是服务端接受新连接的唯一入口在这里创建 QP 并调用rdma_accept。RDMA_CM_EVENT_ESTABLISHED触发后 QP 已进入 RTS 状态可以直接 post 请求。用 CM 的好处是连接状态机由内核维护不用自己处理各种边界情况。最后给一个我常用的压测脚本模板把绑核、多 QP、多消息尺寸串起来一条命令跑完出报告#!/bin/bash # rdma_bench.sh - 一键跑完带宽和延迟基线 DEVmlx5_0 PEER192.168.1.10 NUMA0 echo 延迟测试 (2B-64B) numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_lat -d $DEV -F -n 10000 $PEER echo 单 QP 带宽 numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_bw -d $DEV -a -F --report_gbits $PEER echo 8 QP 带宽 numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_bw -d $DEV -q 8 -a -F --report_gbits $PEER-n 10000控制延迟测试的迭代次数次数太少结果不稳。这个脚本我一般放在部署仓库里每次换硬件或调网络参数后重跑一遍对比历史数据性能有没有退化一目了然。RDMA 调优最忌讳凭感觉所有改动都要有基线数据支撑不然改着改着就不知道哪一步把性能搞坏了。希望帮到你。本文还有配套的精品资源点击获取 RDMA技术调研：RoCEv2与InfiniBand选型、Verbs编程及性能调优实战
简介这是一份面向网络与系统方向工程师、高性能计算及数据中心从业者的RDMA技术调研文档适合希望系统理解远程直接内存访问原理、协议选型与编程接口的初中级读者。内容围绕零拷贝、内核旁路与CPU卸载三大核心优势展开梳理Infiniband、RoCE、iWARP三种协议的差异与适用场景并讲解WQ、SQ、RQ、CQ、QP等关键术语及SEND/RECV、WRITE/READ、ATOMIC等通信操作同时介绍verbs与rdma-core两种编程路径可帮助读者建立从概念到落地的完整认知框架。资源包共1个PDF文件约1.01MB篇幅紧凑、结构清晰便于按章节检索与快速通读。目前已有528人学习下载适合作为RDMA入门调研与方案选型的参考材料。1. RDMA 技术调研一份 PDF 背后到底藏着哪些工程决策第一次认真翻 RDMA 技术调研类 PDF 的人多半是被同一类问题逼过来的训练集群里 GPU 利用率上不去分布式存储的尾延迟忽高忽低或者跨节点 RPC 的 CPU 占用高得离谱。标题写的是「RDMA 技术调研」但真正要回答的其实是——在我的场景里RDMA 到底值不值得上上了之后怎么配、怎么测、怎么排错。这份调研不是让你背协议栈而是帮你把 RoCEv2、InfiniBand、iWARP 三条路线、Verbs 编程模型、以及 PFC/ECN 这套拥塞控制组合拳落到一张能拍板的选型表上。适合正在做 AI 训练网络、分布式存储、高频交易中间件的工程师也适合被「无损网络」四个字忽悠过、想搞清楚代价的人。下面按「先立住概念 → 再动手跑通 → 最后避坑」的顺序展开能抄的命令和参数我都给全。2. 三条技术路线怎么选RoCEv2、InfiniBand 与 iWARP 的取舍RDMA 的核心承诺只有一句话让网卡直接读写远端内存绕过内核协议栈和 CPU 拷贝。但「怎么绕过」在不同路线里差别巨大选错路线后面全是坑。2.1 三种 RDMA 实现的本质差异InfiniBand 是原生方案从链路层到传输层整套自研天生支持无损和拥塞控制性能最稳代价是专用交换机和 HCA 卡生态相对封闭。RoCEv2 把 IB 的传输层架在 UDP/IP 之上能跑在标准以太网交换机上是当下数据中心最主流的选择但它把「无损」这件事交给了以太网的 PFC 和 ECN 去兜底配置复杂度陡增。iWARP 把 RDMA 架在 TCP 之上兼容性最好、对网络设备要求最低但 TCP 的重传和拥塞控制会拖累延迟实际部署远少于前两者。一句话选型追求极致稳定和低延迟、预算充足选 InfiniBand要在现有以太网上做大规模部署、能接受调优成本选 RoCEv2只在特定兼容场景下才考虑 iWARP。2.2 用 ibv_devinfo 和 perftest 确认硬件与链路能力选型之前先摸清手里有什么卡、什么链路。装好 OFED 或发行版自带的 rdma-core 后第一件事是确认设备状态。# 查看本机所有 RDMA 设备及其端口状态 ibv_devinfo -v # 关注输出里的几个关键字段 # state: PORT_ACTIVE - 端口已激活可以通信 # link_layer: Ethernet - 说明是 RoCEInfiniBand 会显示 InfiniBand # active_speed: 100.0 Gbps - 实际协商速率和标称不符要查线缆/光模块 # active_width: 4X - 链路宽度state不是PORT_ACTIVE时先别急着写代码八成是链路或驱动问题。link_layer直接决定你后面走 RoCE 还是 IB 的配置路径这个字段看错后面 PFC 配置全白做。确认链路后用 perftest 套件做裸带宽和延迟基线这是判断「值不值得上」的第一手数据。# 服务端监听等待客户端连接 ib_write_bw -d mlx5_0 -a -F --report_gbits # 客户端连接服务端 IP跑 10 秒带宽测试 ib_write_bw -d mlx5_0 -a -F --report_gbits 192.168.1.10 # 延迟测试换成 ib_write_lat参数含义一致 ib_write_lat -d mlx5_0 -F 192.168.1.10-d指定设备名-a跑所有消息尺寸-F允许在不同 CPU 上跑避免绑核干扰--report_gbits让结果以 Gb/s 显示。带宽测试看大消息1MB 以上能否打满链路延迟测试看小消息2 字节到 64 字节的往返时间。如果 100G 链路只跑出 30G先查 PCIe 带宽和 NUMA 绑定别怀疑网卡。2.3 RoCEv2 无损网络的两个必调开关PFC 与 ECNRoCEv2 最大的坑在于它假设网络无损但以太网默认会丢包。丢包一旦发生RDMA 的重传代价极高性能断崖式下跌。所以必须配 PFC优先级流控和 ECN显式拥塞通知。PFC 的作用是当某个优先级的队列快满时向上游发暂停帧让上游先别发。配置要点是给 RDMA 流量打上特定 DSCP 优先级常见是 3 或 4在交换机所有端口上为这个优先级开启 PFC。ECN 则是在拥塞初期就标记数据包让接收端通知发送端降速避免走到 PFC 触发暂停那一步。# 在主机侧为 RoCE 流量设置 DSCP 优先级以优先级 3 为例 # 先看网卡是否支持 trust dscp mlnx_qos -i ens1f0 # 把 RoCE 流量映射到 TC3并开启 PFC mlnx_qos -i ens1f0 --trust dscp --pfc 0,0,0,1,0,0,0,0 # 查看当前 PFC 和优先级映射状态 mlnx_qos -i ens1f0 -s--pfc 0,0,0,1,0,0,0,0表示只对优先级 3 开启 PFC其余关闭。全开 PFC 会引发死锁和广播风暴这是血泪经验。交换机侧必须做同样的优先级映射两端不一致等于没配。ECN 的阈值设置更玄学一般从交换机端口的 30% 队列深度开始调太低会误标记导致降速太高则起不到预防作用。3. Verbs 编程模型从注册内存到完成队列的最小闭环搞清路线后真正写代码时面对的是 Verbs API。它的心智模型和 socket 完全不同第一次接触容易懵。3.1 QP、CQ、MR 三个核心对象的关系RDMA 通信的基本单位是 Queue PairQP分发送队列和接收队列。每个 QP 绑定一个 Completion QueueCQ操作完成后产生 Completion Queue EntryCQE。内存必须先注册成 Memory RegionMR拿到 lkey/rkey 才能被网卡直接访问。这套设计的目的是所有资源提前建好数据路径上零系统调用。一次典型的双边操作流程是注册 MR → 创建 CQ → 创建 QP → 交换 QP 信息通过带外通道→ 修改 QP 状态到 RTS → 提交发送/接收请求 → 轮询 CQ 拿完成事件。单边操作RDMA Read/Write不需要远端 CPU 参与但要求提前交换 rkey 和远端地址。3.2 一个可运行的双边发送最小示例下面这段代码展示发送端核心逻辑省略了连接建立和 QP 状态迁移的样板代码重点看资源创建和数据路径。#include infiniband/verbs.h // 1. 注册内存区域拿到 lkey struct ibv_mr *mr ibv_reg_mr(pd, buf, BUF_SIZE, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ); // IBV_ACCESS_LOCAL_WRITE 允许本端网卡写入这块内存 // REMOTE_WRITE/READ 允许远端通过 rkey 直接访问单边操作必须加 // 2. 创建 CQ容量 16 表示最多容纳 16 个未处理的完成事件 struct ibv_cq *cq ibv_create_cq(ctx, 16, NULL, NULL, 0); // 3. 创建 QPsend_cq 和 recv_cq 可以指向同一个 CQ struct ibv_qp_init_attr qp_attr { .send_cq cq, .recv_cq cq, .qp_type IBV_QPT_RC, // RC Reliable Connection最常用 .cap { .max_send_wr 16, .max_recv_wr 16, .max_send_sge 1, .max_recv_sge 1 } }; struct ibv_qp *qp ibv_create_qp(pd, qp_attr); // 4. 提交发送请求 struct ibv_sge sge { .addr (uintptr_t)buf, .length MSG_SIZE, .lkey mr-lkey }; struct ibv_send_wr wr { .wr_id 1, .sg_list sge, .num_sge 1, .opcode IBV_WR_SEND, .send_flags IBV_SEND_SIGNALED // 只有带 SIGNALED 才会产生 CQE }; struct ibv_send_wr *bad_wr; ibv_post_send(qp, wr, bad_wr); // 5. 轮询 CQ 等待完成 struct ibv_wc wc; while (ibv_poll_cq(cq, 1, wc) 0) { /* 忙等生产环境可加退避 */ } if (wc.status ! IBV_WC_SUCCESS) { // wc.status 是排错第一现场常见值 // IBV_WC_RNR_RETRY_EXC_ERR - 接收端没及时 post recv // IBV_WC_RETRY_EXC_ERR - 链路或对端 QP 异常 // IBV_WC_LOC_PROT_ERR - lkey 或权限不对 }关键参数说明IBV_QPT_RC是可靠连接保证不丢不乱序代价是需要维护连接状态IBV_SEND_SIGNALED决定是否产生完成事件批量发送时只给最后一个 WR 加 SIGNALED 能显著降低 CQ 压力这是性能优化的常见手法max_send_wr设太小会在高并发时 post 失败设太大浪费内存一般按峰值在途请求数的 1.5 倍估。3.3 单边操作与双边操作的性能分水岭双边 SEND/RECV 需要接收端提前 post recv两端 CPU 都参与。单边 WRITE/READ 只要求接收端提前注册好 MR 并告知 rkey数据路径上接收端 CPU 完全不参与。做分布式存储的数据落盘、AI 训练的梯度同步优先用单边 WRITE能把对端 CPU 从数据搬运里彻底解放出来。但单边操作没有天然的完成通知接收端要么轮询标志位要么用带立即数的 WRITE 触发一个 CQE这是设计时要提前想清楚的。4. 性能调优与验证把带宽和延迟压到硬件极限代码跑通只是及格线真正拉开差距的是调优。这一章讲怎么把 RDMA 的性能榨干以及怎么验证调优是否生效。4.1 用 perftest 做多维度基线测试单条 QP 往往打不满链路因为单个 QP 的吞吐受限于 PCIe 通道和网卡队列深度。要测出硬件极限得用多 QP 并发。# 服务端启动 8 个 QP 的带宽测试 ib_write_bw -d mlx5_0 -q 8 -a -F --report_gbits # 客户端对应连接 ib_write_bw -d mlx5_0 -q 8 -a -F --report_gbits 192.168.1.10 # 测试不同消息尺寸下的表现重点看这几个点 # 2B / 64B - 延迟敏感型看 ib_write_lat # 4KB - 典型 RPC 消息 # 1MB - 大块传输看能否打满-q 8表示用 8 个 QP 并发。如果单 QP 只有 40G、8 QP 能到 95G说明瓶颈在单 QP 的队列深度或 PCIe不在链路。这时可以考虑增大max_send_wr、开启多队列或者用 SR-IOV 虚拟化多张逻辑网卡。4.2 绑核、NUMA 与 PCIe 拓扑的隐形影响RDMA 性能对 CPU 和内存位置极其敏感。网卡插在 CPU0 的 PCIe 槽内存却分配在 CPU1 的 NUMA 节点跨节点访问会让带宽直接腰斩。# 查看网卡挂在哪颗 CPU 下 cat /sys/class/net/ens1f0/device/numa_node # 查看网卡 PCIe 链路速率和宽度 lspci -vv -s $(ethtool -i ens1f0 | grep bus-info | awk {print $2}) | grep -E LnkCap|LnkSta # 跑测试时把进程绑到网卡同侧 CPU numactl --cpunodebind0 --membind0 ib_write_bw -d mlx5_0 -a -FLnkSta显示的实际速率如果低于LnkCap说明 PCIe 降速了常见原因是插槽电气规格不够或 BIOS 里 PCIe 速率被限制。numactl绑核绑内存是必做项不绑的话测试结果波动能到 30% 以上这种玄学问题排查起来最费时间。4.3 用 ibv_rc_pingpong 快速验证连通性正式压测前先用 pingpong 确认两端 QP 能正常握手比直接上 perftest 更容易定位问题。# 服务端 ibv_rc_pingpong -d mlx5_0 -g 3 # 客户端-g 3 表示用 gid index 3RoCEv2 通常对应这个 ibv_rc_pingpong -d mlx5_0 -g 3 192.168.1.10-g指定 GID 索引RoCEv2 的 IPv4 映射 GID 一般在 index 3 附近用show_gids命令确认。如果 pingpong 不通但ibv_devinfo显示端口正常八成是 GID 索引选错或防火墙挡了 UDP 4791 端口。5. 避坑与排查RDMA 部署中最容易翻车的五件事这一章全是踩过的坑按「现象 → 原因 → 解决」写遇到问题直接对号入座。坑一PFC 全优先级开启导致网络死锁。现象是配置完 PFC 后整个网络间歇性卡死所有流量都受影响。原因是 PFC 对全部优先级生效一旦某个优先级拥塞触发暂停帧暂停帧本身也可能被阻塞形成循环等待。解决是只对 RDMA 流量所在的单一优先级开启 PFC其余优先级保持关闭并在交换机侧严格对齐。坑二ECN 阈值设太低带宽反而下降。现象是开了 ECN 后吞吐不升反降CQE 里频繁出现重传。原因是 ECN 标记阈值过低轻微拥塞就被标记发送端频繁降速。解决是把阈值从队列深度的 30% 起步逐步上调同时观察交换机端口的 ECN 标记计数标记率超过 10% 就说明阈值偏低。坑三MR 注册时权限给少了单边操作报 LOC_PROT_ERR。现象是 RDMA WRITE 提交后 CQE 返回IBV_WC_LOC_PROT_ERR。原因是注册 MR 时没加IBV_ACCESS_REMOTE_WRITE或者 lkey 传错。解决是单边操作必须同时加 LOCAL_WRITE 和 REMOTE_WRITE且发送端用的 lkey 必须来自同一块 MR。坑四接收端 recv 队列耗尽报 RNR_RETRY_EXC_ERR。现象是双边通信跑一段时间后连接断开CQE 显示 RNR 重试超限。原因是接收端 post recv 的速度跟不上发送端接收队列空了。解决是接收端提前批量 post 足够多的 recv WR或者改用单边 WRITE 彻底绕开这个问题。坑五跨 NUMA 跑测试性能数据完全不可信。现象是同样的配置两次测试带宽差一倍。原因是进程和内存没绑到网卡同侧 NUMA 节点。解决是所有性能测试和实际部署都用numactl绑核绑内存并把这条写进部署脚本别靠人记。6. 进阶技巧用 RDMA CM 管理连接与一个压测脚本模板手写 QP 状态迁移和带外交换 QP 信息很繁琐生产环境一般用 RDMA CMConnection Manager来管理连接生命周期。它把地址解析、路由解析、连接建立都封装成事件回调代码量能少一半。// RDMA CM 事件循环的核心骨架 struct rdma_event_channel *ec rdma_create_event_channel(); struct rdma_cm_id *id; rdma_create_id(ec, id, NULL, RDMA_PS_TCP); // 服务端绑定地址并监听 rdma_bind_addr(id, (struct sockaddr *)addr); rdma_listen(id, 8); // 事件循环处理连接请求、建立、断开 struct rdma_cm_event *event; while (rdma_get_cm_event(ec, event) 0) { switch (event-event) { case RDMA_CM_EVENT_CONNECT_REQUEST: // 对端发起连接在这里创建 QP 并 accept break; case RDMA_CM_EVENT_ESTABLISHED: // 连接就绪可以开始收发 break; case RDMA_CM_EVENT_DISCONNECTED: // 对端断开清理资源 break; } rdma_ack_cm_event(event); }RDMA_CM_EVENT_CONNECT_REQUEST是服务端接受新连接的唯一入口在这里创建 QP 并调用rdma_accept。RDMA_CM_EVENT_ESTABLISHED触发后 QP 已进入 RTS 状态可以直接 post 请求。用 CM 的好处是连接状态机由内核维护不用自己处理各种边界情况。最后给一个我常用的压测脚本模板把绑核、多 QP、多消息尺寸串起来一条命令跑完出报告#!/bin/bash # rdma_bench.sh - 一键跑完带宽和延迟基线 DEVmlx5_0 PEER192.168.1.10 NUMA0 echo 延迟测试 (2B-64B) numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_lat -d $DEV -F -n 10000 $PEER echo 单 QP 带宽 numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_bw -d $DEV -a -F --report_gbits $PEER echo 8 QP 带宽 numactl --cpunodebind$NUMA --membind$NUMA \ ib_write_bw -d $DEV -q 8 -a -F --report_gbits $PEER-n 10000控制延迟测试的迭代次数次数太少结果不稳。这个脚本我一般放在部署仓库里每次换硬件或调网络参数后重跑一遍对比历史数据性能有没有退化一目了然。RDMA 调优最忌讳凭感觉所有改动都要有基线数据支撑不然改着改着就不知道哪一步把性能搞坏了。希望帮到你。本文还有配套的精品资源点击获取