RoCE v2收发模块核心机制：QP状态机与PSN/ACK工程实践-北京尧图网络

如果让我用一句话形容这段时间做 RoCE v2 收发模块设计的感受那就是“协议看着薄薄一层实现起来满身都是刺”。RoCE v2 在绝大多数宣传材料里只有一句话RDMA over Converged Ethernet version 2把 InfiniBand 的报文用 UDP/IP 封装起来端口号 4791。但真正落到发送和接收模块的代码与状态机上你会发现每一个决定都会影响丢包后的恢复速度、乱序包的去重逻辑、CPU 与网卡的交互次数甚至直接决定一条链路能不能跑到线速。这篇文章不打算重复教科书里那些分层图而是想从模块设计者的视角把 RoCE v2 发送、接收两条路径各自要解决的问题拆开包怎么切、头怎么拼、PSN 怎么维护、ACK/NAK 怎么回、乱序和重传怎么收敛。内容会更适合正在做网卡固件、RDMA 驱动、或者基于 RoCE 做高性能中间件的人也希望对 RoCE v2 内部机制好奇的读者有帮助。整篇我会按协议定位、发送模块、接收模块、收发协同与调试的顺序走每一步都尽量说清楚“为什么这样做”。1. RoCE v2 的协议定位UDP 不是偷懒是被规模倒逼的选择1.1 从 GRH 到 IPUDP一次被网络规模倒逼的演进RoCE v1 的报文其实很简单以太网头后面直接跟一个 IB 的 GRHGlobal Routing Header总共 40 字节里面放了源 GID、目的 GID 和流量等级。那时候大家觉得二层以太网加 PFC 流控就够用了RDMA 只在同一个二层域内跑。可是数据中心一旦变大跨机柜、跨接入层、跨汇聚层的场景越来越多纯二层的限制立刻显现出来VLAN 可以解决广播域划分却解决不了跨子网路由。你总不能为了跑 RDMA 专门把一个集群划在一个大二层里那样广播域和故障域都太大了。RoCE v2 做的事情本质上是把 GRH 里的路由信息“翻译”成 IP 头再加一个 UDP 头。源 SGID 对应源 IPDGID 对应目的 IPUDP 目的端口固定为 4791源端口由发送侧按需生成同一对 QP 的流一般会固定一个源端口不同流可以用不同源端口。为什么偏偏选 UDP 而不选 TCP这是很多人会问的第一个问题。答案其实很务实RDMA 的可靠性根本不需要 TCP 那套滑动窗口、拥塞控制、按序重组机制这些逻辑全部由上层的 RC QP可靠连接状态机来管。UDP 在这里的角色只是一个“薄管道”保留无状态、低解析成本、低延迟的特性同时给交换机提供 ECMP等价多路径hash 的输入。TCP 的复杂度、重传问题和首字节延迟对 RDMA 来说完全不可接受。另外一个生态原因数据中心交换机对 UDP 的转发和 hash 已经非常成熟支持 RoCE 的交换机普遍会针对 4791 端口做特殊优化。1.2 可靠性边界在 QPUDP 只是一种运输载体理解 RoCE v2最关键的是把“可靠”两个字放在正确的位置。UDP 本身会丢包但这不影响 RC QP 的可靠性语义。RC QP 通过包序号 PSN、AETHACK 扩展头、重传计时器和重试计数器实现了类似 TCP 但又比 TCP 更轻量的确认与重传。这对发送和接收模块的设计有一个直接影响接收模块必须有能力识别“重复包”和“乱序包”前者通常是 ACK 丢失导致发送端重传后者通常是网络多路径导致。硬件层面必须内置这些逻辑不能让软件接收路径去逐个判断否则线速就是一句空话。我用一个类比帮刚入门的朋友理解UDP 相当于公路本身它不保证车辆不坏、不保证不堵车而 RC QP 是交通调度中心每一辆车数据包都有编号PSN调度中心发现少了车会让出发地重发发现重复车就只确认不处理发现车序错了就缓存等待。调度逻辑都在收发两端的“调度中心”QP 状态机里不在公路上。1.3 一张表看懂发送端要拼装的头部真正实现 RoCE v2 发送模块时你最常面对的其实是“这个包要从第几字节开始写 BTH在哪里插入 RETHICRC 怎么算”这类问题。下面这张表是我在设计模块时反复对照的层次头部/字段关键信息处理方L2以太网头源/目的 MAC、EtherType0x0800 IPv4 / 0x86DD IPv6网卡 MAC 层L3IP 头源/目的 IP用于跨子网路由网卡 IP 层/交换机L4UDP 头目的端口 4791源端口用于流哈希网卡/交换机IBBTH12 字节Opcode、目的 QPN、PSN、PKey收发模块核心IB扩展头可选RETHRDMA 写/读、AETHACK、原子操作头收发模块核心Payload数据用户数据DMA 引擎IBICRC4 字节不变字段 CRC硬件L2FCS4 字节以太网 CRC网卡/交换机这里我想单独强调 ICRCICRC 是 IB 传输层的 CRC它的特点是只对“不可变字段”计算也就是说从发送端发出到接收端中间任何交换机都不能改动这些字段。VCRC可变 CRC则允许路由器改 TTL 等字段其实在 RoCE v2 里这种情况少见。ICRC 在接收端做最终校验一旦不符说明包在链路中被修改直接丢弃并报 CRC 错误。2. 发送路径一个 WQE 怎么变成一串带序号的包2.1 发送触发的两个动作在 RDMA 里软件把发送请求提交给网卡的过程非常精简。应用准备好数据后会构造一个 WQEWork Queue Element工作队列元素写到 SQ发送队列的硬件队列中然后写一次门铃Doorbell寄存器通知网卡“有新任务”。网卡收到门铃后通过 DMA 读取 WQE、读取用户内存里的数据再按协议把它变成若干个网络包。写门铃这个动作是发送路径上为数不多的 CPU 到 PCIe 寄存器写操作延迟和频率直接关系到 CPU 开销。模块设计时一般支持“门铃合并”软件一次性提交多个 WQE 后只写一次门铃网卡自动批量调度。某些硬件还支持把门铃写入与 WQE 发布合并到一次 PCIe 事务中。这个优化对高吞吐场景非常关键尤其小消息模型下减少门铃次数往往能省出 10%~20% 的 CPU。2.2 WQE 和 SGE 的数据结构要点发送模块从内存读到的 WQE 长什么样简化后大致类似下面的结构。真实硬件里可能还有标记位、分片标志、原子操作参数等但核心就是“到哪里拿数据、拿多少、送给谁、怎么送”。struct sq_wqe { uint8_t opcode; /* RDMA_WRITE / RDMA_READ / SEND */ uint16_t num_sge; /* 本地 SGE 数量 */ uint64_t local_addr0; /* SGE1本地数据地址 */ uint32_t local_len0; /* SGE1长度 */ uint64_t remote_addr; /* 对端 MR 中的虚拟地址 */ uint32_t rkey; /* 对端注册的 RKey */ uint64_t remote_len; /* 本次传输长度 */ };一个 WQE 通常带 1~多个 SGEScatter-Gather Element也就是“数据不是一整块连续内存”时网卡需要从多个地址拼出一个完整的消息。拼接这件事在 DMA 层实现简单但如果消息超过 MTU需要按包为单位拆分而拆分点正好落在某个 SGE 中途时处理就麻烦了。所以发送模块内部一般会维护一个“当前取数指针”指向 SGE 数组中的某项和该项内的偏移每发出一个数据包就前进相应长度。这听起来简单真正做的时候要考虑字节序、未对齐长度、以及最后一个包是否需要 padding。有些网卡对齐到 16B 比较方便 DMA所以实现时通常把 SGE 拼接逻辑封装成一个统一的“字节流视图”避免在中断上下文里逐个判断。2.3 分段、PSN 分配和扩展头放置这是发送模块的核心。一个 WQE 代表的是一次完整的 RDMA 操作但对于超过单包长度限制取决于 MTU的消息网卡必须把它拆成多个数据包包与包之间用连续的 PSN 关联。以 RDMA 写为例假设 MTU 是 4096应用提交了一个 64KB 的 RDMA_WRITE发送模块会把它拆成 16 个数据包。第一个数据包除了 BTH还要带一个 RETH16 字节用来告诉接收端“这次写操作要写到哪个地址、用哪个 RKey、总长多少”。后面的 15 个包不需要再带 RETH因为它们只负责搬运剩余数据接收端可以根据 PSN 连续性判断它们属于同一个 WQE。if (first_packet_of_wqe) { build_bth(opcode RDMA_WRITE_FIRST, psn wqe-start_psn); build_reth(remote_addr, rkey, total_len); } else { build_bth(opcode RDMA_WRITE_ONLY / RDMA_WRITE_LAST, psn); }为什么只在第一个包放 RETH省带宽只是一个原因更重要的是减少接收端处理状态。接收端只需要在收到第一个包时解析一次目标地址和 RKey后面的包按地址直接 DMA 到连续内存即可。PSN 的分配要全局考虑每个发送 WQE 在入队时分配一个起始 PSN每发一个数据包 PSN1。所有未确认的包都要保留在重传缓冲中。PSN 是 24 位的会回绕所以模块不仅要维护“下一次要使用的 PSN”还要维护“最早未被确认的 PSN”这两者之差不能超过协议窗口上限一般与硬件重传资源相关。否则会出现 PSN 回绕后无法区分新包和旧包的问题。2.4 发送完成语义必须看到 ACK这里有个新手常常踩的坑RDMA 写的发送完成并不是“把包放到线上”就算完成而是要等到对端回 ACK 之后才算。硬件层面的完成事件WC必须反映这个语义。对应到模块设计发送完成逻辑有两种简单方式每收到一个 ACK根据 ACK 中的 MSN 确认哪些包已被确认释放对应重传缓冲然后为对应 WQE 生成 WC。部分完成某些硬件允许按包粒度释放缓冲但 WC 仍按 WQE 粒度投递。这样可以减小重传缓冲占用又能让应用尽早收到完成通知。这个设计决策直接影响网卡缓存资源利用率和 CPU 可见的完成延迟。实测中对于大块 RDMA 写开启部分完成之后应用的下一轮提交能提前约数微秒吞吐提升比预想明显。2.5 重传缓冲与窗口限制发送模块必须保留“已发送但未确认”的数据副本。在网卡上这块缓冲通常是 SRAM很贵所以窗口大小不可能无限大。协议上 PSN 范围有限工程上缓冲区更是瓶颈。设计时我会建议画一条“发送窗口”的边界已确认的包可释放已发送未确认保留在重传缓冲不能释放未发送但已在 WQE 中等待调度发送窗口满了以后调度器必须停止从 SQ 取新 WQE直到收到 ACK 释放缓冲。这个“背压”逻辑如果做得不好会出现系统吞吐抖动。有一个常见做法是重传缓冲按 QP 分配尽量让大窗口的 QP 不阻塞小窗口 QP。3. 接收路径从线缆上的包到应用感知到的 WC3.1 接收侧校验链先做什么后做什么很重要接收模块的入口是包过滤出口是 DMA 写入用户内存和生成完成通知 WC。中间每一步的检查顺序决定了错误包干扰正常包的程度。一个典型的接收路径如下以太网头解析目的 MAC 是否本机、EtherType 是否 IP。IP 头检查目的 IP 是否本机若开启 RoCE v2 over IPv6则检查 IPv6 头。UDP 头检查目的端口是否为 4791。BTH 解析取出 Opcode、目的 QPN、PSN。QPN 匹配找到对应的 QP 上下文如果找不到 QPN则需要回送 RNR/NAK 或者直接丢弃取决于协议语义和硬件策略。PSN 校验与期望 PSNE_PSN对比。扩展头解析如果是 RDMA 写/读的第一个包解析 RETH校验 RKey。权限校验和 DMA 地址翻译将报文中的地址VA映射到物理地址确认本地内存区域有相应权限。DMA 写入数据可能涉及跨页、跨 SGE。生成 ACK/NAK并在必要时投递 WC。顺序不是随便定的。QPN 匹配和 PSN 校验必须很靠前因为只需要几纳秒的查找RKey 校验和内存翻译涉及页表遍历相对昂贵应该在确认包合法后再做。这样设计可以避免错误包把昂贵的页表查找占满。实际测试里非法 QPN 的包如果能被前置过滤接收 CPU 占用可以显著下降。3.2 PSN 校验、重复包和乱序包的处理接收端对每个 QP 维护一个期望 PSNE_PSN表示下一个应该收到的包的序号。收到包后PSN E_PSN正常处理E_PSN。PSN E_PSN重复包通常是发送端因为 ACK 丢失而重传。接收端应该丢弃该包不再 DMA但必须回一个 ACK而且 ACK 中携带的确认序号要能达到发送端期望的最新值。这个“重复包也回 ACK”的细节非常重要它帮助发送端更快释放重传缓冲。PSN E_PSN出现空洞。RC 服务要求数据按序投递因为 RDMA 写会直接把数据 DMA 到内存如果乱序写入同一块区域后续数据可能覆盖先到的数据逻辑就乱了。乱序包怎么处理有的实现立刻回 NAKNAK with PSN sequence error让发送端从这个空洞开始重传更精细的实现会设置一个 reorder buffer先缓存后续的包同时发起重传请求等前面缺的包到达后再按序提交。这个选择涉及性能和复杂度权衡reorder buffer 需要内存和 DMA 管理小包场景投入产出比低大包场景能明显减少重传流量。发送端同样要维护一个“重传起点”变量。收 NAK 后把发送窗口回退到 NAK 指出的 PSN重新传输未确认的包。3.3 ACK 与 NAK 的生成逻辑接收模块对每个正常收到的数据包生成一个 ACK。这里的“ACK”严格来说是 AETHACK 扩展头里嵌入了确认信息。AETH 结构简单说前 2 位指示类型ACK、NAK、RNR接收未就绪。后面 24 位是 MSNMessage Sequence Number表示该方向成功接收到的包序号。NAK 的触发条件主要包括PSN 错误收到的包不连续且无法用重排解决。RKey 错误发送方提供的 RKey 在本机内存区域里没有对应权限。长度错误报文长度与 RETH 中的总长度矛盾。这里有一个容易忽略的语义RNR NAK 表示接收端不是出错而是暂时没有可用的接收 WQE接收队列为空。这种情况下发送端不能简单重传而要等一段时间再重试。RNR 的处理是 RDMA 可靠传输里最复杂的部分之一在大型集群里经常出现“接收队列深度太小导致 RNR 风暴”的问题。模块设计时要把 RNR 重试次数上限和超时做成可配置的默认值可以参考硬件厂商建议但真实部署时基本都要调大。补充一句RDMA 读请求的响应是“响应包”Read Response它们也要有对应的完成机制。接收模块对于读响应要负责将数据 DMA 到请求方指定的本机地址并最终生成 WC。3.4 从包到内存RKey 与地址翻译接收模块最终要把 payload 写到本机内存。RKey 是发送方放在 RETH 里的一个权限令牌接收端用它去查找内存区域MR的映射表拿到虚拟地址、长度、权限位。设计接收模块时的关键点RKey 校验通过后地址翻译必须在 DMA 引擎里做而且要处理跨页、跨区域边界的情况。报文长度超过一个页时DMA 引擎要生成多个 PCIe 读写事务。这个逻辑如果放在主控 CPU 里会拖慢路径所以做固件或硬件模块时我通常把页表遍历交给专门的地址翻译单元类似 MMU主控只需要维护 TLB 的命中与未命中。很多线上问题和这里有关比如 RKey 过期、内存注销后仍有迟到包到达、VA 重复映射等。接收模块必须能优雅处理这些情况查不到 RKey 对应的 MR就回 NAK 而不是直接丢弃否则发送端会一直重传永远不知道失败原因。3.5 WC 完成通知是怎么生成的应用感知“操作已完成”依赖的是 CQ 里的 WCWork Completion。不同类型的操作WC 投递时机不同RDMA 写接收端 DMA 完成后发送端收到 ACK 后投递 WC。RDMA 读接收端收到读请求后返回数据发送端收到数据后会投递 WC。SEND接收端把数据 DMA 到接收 WQE 指向的缓冲区后投递接收侧 WC并回 ACK发送端收到 ACK 后投递发送侧 WC。WC 里至少要包含 wr_id让应用知道这是哪个请求、状态字段、字节数等。为了减少 PCIe 中断次数CQ 通常支持聚合多个 WC 攒一起写内存再触发一次中断。中断避让和聚合策略对 CPU 占用影响很大配置要点后面会提到。4. 收发协同、QP 状态机与真实环境上的排查心得4.1 QP 状态机是收发逻辑的大前提收发模块虽然各管各的但都受 QP 状态机约束。一个 RC QP 的状态大致是Reset → Init → RTR → RTS → 可选的 SQ Drain / Error。状态切换通过 Modify QP 操作完成关键时机RTRReady to Receive一般在应用调用修改 QP、设置接收 PSN 之后这时接收模块才开始处理对端发来的包。RTSReady to Send在 RTR 基础上增加发送能力一般同时设置发送 PSN。进入 Error 状态后发送和接收模块都要把对应队列中的 WQE 全部标记为错误并停止新调度。实际工程里常见问题之一接收侧已经 RTR但发送侧还没 RTS对端就发数据过来了。这种“对端比预期快”的场景接收模块必须能容忍并正确处理通常会收到包并回 NAK或者直接按 RNR 处理。设计时不要把逻辑建立在“双方永远同步”的理想假设上所有的握手建链流程都要考虑时间差。4.2 超时和重传参数设置不当比丢包更致命可靠的 RC 传输依赖超时重传。参数主要看下面几个参数含义参考方向Retry Count包重传的最大次数一般 7~15过大掩盖故障过小误判RNR Retry Count收到 RNR 后重试的次数集群拥塞时建议调大ACK 超时时间等 ACK 的最长时间需要大于端到端 RTT 加排队波动RNR 超时时间RNR 之后等待多久重发对接收到队列压力敏感参数之间的关系不是独立的。比如 ACK 超时太短只在瞬时拥塞中就可能触发重传重传加剧拥塞形成恶性循环太长则故障恢复时间以秒计。跨机房的 RDMARTT 较高比同机架场景需要更大的超时余量宁可多几倍重传时间也不要频繁误重传。这块还有一个容易忽略的点网卡重传定时器和 CPU 的时钟源有关系多核环境下如果收包中断在某个 CPU 上处理延迟大ACK 晚到几微秒就可能触发发送端重传。遇到“莫名其妙重传很多”的案例先看 CPU 中断绑定和网卡多队列配置别急着调重传参数。4.3 线上问题排查先看计数器再动手抓包我自己的排查顺序永远是先看计数器再看抓包最后才改参数。常用命令清单# 查看网卡丢包、CRC 错误、重传相关计数器 ethtool -S eth | grep -E rx_crc|rx_error|tx_retry|rx_roce # 查看本机 RDMA 设备能力、GID、端口速率 ibv_devinfo -v # 查看当前 QP 状态实际使用中可能需要专用工具 rdma resource show qp # 在发送端抓 RoCE v2 报文 tcpdump -i eth udp port 4791 -w roce_send.pcap # 在接收端同时抓对比时间戳 tcpdump -i eth udp port 4791 -w roce_recv.pcap几个常见的现象和判断现象可能原因先查什么传输速率远低于线速MTU 太小、门铃过多、CQ 中断聚合差MTU、门铃合并、中断绑定偶发重传风暴ACK 超时设置过短、交换机丢包两端抓包看是否同一包发出多次接收端 CPU 高CQ 中断集中在某核、RNR 风暴中断分布、RQ 深度链路层 CRC 错误多光模块、线缆、信号完整性问题ethtool -S 里的 rx_crc_errors抓包时有一个细节RoCE v2 抓到的包通常是 UDP 4791但部分抓包工具默认不解析 IB BTH 里的 QPN/PSN需要把自定义协议解析打开或者直接看 UDP payload 的十六进制。有个笨办法但很有效把 4791 端口的包导出后用抓包分析工具“Decode As”重新解析成 RoCE v2就能看到 BTH 完整字段。4.4 性能相关的几点实现心得最后讲几个我在调节点性能时反复验证过的点算是给收发模块设计收个尾。第一MTU 一定要尽量往 4096 靠。RoCE v2 的报文大小受路径 MTU 限制而路径 MTU 由 IB 参数和交换机配置共同决定。同样是 100Gbps 链路4KB MTU 比 2KB MTU 少一半的包数CPU 和 DMA 引擎处理开销都会下降。前提是交换机必须支持 jumbo frame这个经常被忽略。第二中断聚合与多队列要一起看。CQ 映射到多个中断向量按 CPU 分开避免所有完成事件都灌到同一个核上。在 irqbalance 被禁用的环境下手动把队列中断绑定到不同核这个改动在很多测试里能让总吞吐提升 5%~15%代价是要自己维护中断亲和性。第三门铃合并在小包场景最有效。如果应用平均消息只有几百字节每个 WQE 都写一次门铃PCIe 写入会成为瓶颈。把多个小 WQE 攒在一起批量提交门铃次数能降一个数量级。不少库已经支持这种批量路径但用户侧代码往往没有真正使用。第四别把 RQ接收队列配得太浅。许多默认配置把 RQ 深度设得很小以节省内存但 RC 流下对端一旦突发接收侧拿不到 WQE 就会产生大量 RNR 重传网络利用率瞬间下降。我把 RQ 深度从 64 调到 256 之后某次压测的吞吐曲线从“锯齿状”变成了平滑直线差异非常直观。第五关于重传缓冲资源不同的 QP 是大户。一个 64KB 的未确认写操作在 4KB MTU 下占 16 个包的缓冲如果 QP 数量多缓冲会非常吃紧。建议把重传窗口参数和接收侧的 ACK 频率匹配起来不要让发送端因为缓冲不足而被动限速。如果硬件支持开启“部分完成通知”能显著降低压力。写到这里收发模块的核心设计思路基本都过了一遍。如果让我用一句话收尾我会说RoCE v2 的发送和接收模块本质上是一对互相约束的状态机——发送端拼命把消息切成带序号的包并押着副本等确认接收端按序号把它们拼接回完整消息并不断告诉对端“哪些我收到了”。理解了这两者之间的确认、重传、去重、乱序关系你再看任何具体网卡实现都会有章可循。最后分享一个个人习惯每个新项目上线前我都会在两端同时抓 30 秒的 4791 端口包做基线存档并把 ethtool -S 里的关键计数器记录在案。这样一旦线上出问题不用现猜历史行为直接对比基线就能缩小范围。这个习惯救过我很多次也建议你试试。

RoCE v2收发模块核心机制：QP状态机与PSN/ACK工程实践

相关推荐

Ollama本地大模型部署实战：三平台安装、Modelfile配置与API调用避坑指南

RTX 20/30系显卡DLSS文件替换详解：轻量化模型提升帧率与画质取舍

Salesforce Einstein 实战：邮件同步、线索评分与自然语言搜索配置指南

更多资讯

ST与梯形图混编实战：两种写法差异、适用场景与避坑指南

光猫超级管理员权限获取：Telnet维护端口与配置文件解析实战

绝缘子检测数据集 | 绝缘子检测电力巡检缺陷识别目标检测 YOLO格式 9231期

枯死树木检测数据集 | 枯死树木检测林业巡检生态监测目标检测 YOLO格式深度学习数据集计算机视觉9030期

无人机视角多目标检测数据集 | 无人机视角多目标检测智慧交通自动驾驶目标检测 YOLO格式 9228期

RFID手持机如何实现图书馆藏秒级盘点与精准管理

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？