简介本资源为 InfiniBand 架构规范第 2 卷《物理规范》正式版文档面向从事高性能计算、服务器与存储互连、RDMA 网络开发的工程师及协议研究者用于解决高速链路电气接口设计与信号完整性验证中的标准依据问题。压缩包内仅含 1 个 PDF 文件约 15.14MB内容聚焦高速电气接口章节涵盖 QDR 与 FDR 速率下主机驱动器输出特性、眼图掩模参数 X、Y1、Y2 的定义、确定性抖动与总抖动限值、单位间隔容差以及三抽头 FIR 均衡器预游标与后游标权重调整、16 组预设均衡设置和 AMP 幅度配置等关键指标并引用 IEEE 802.3、OIF-CEI 与 ANSI T11 FC-PI-5 相关规范。文档还给出 S 参数与测试点 TP6 的测量约定便于读者对照表格与图示完成链路预算、均衡调优和合规性测试。目前已有 91 人学习适合需要权威物理层参数支撑设计或排错的技术人员查阅。1. InfiniBand 规范卷 2 第 3 分册到底管什么从链路层到包格式的落地地图如果你正在做 RDMA 网卡驱动、HCA 固件、或者高性能计算集群的底层调优迟早会撞上 InfiniBand 规范文档。这套规范分两卷卷 1 讲架构总览和软件接口卷 2 才是真正管硬件行为的核心——链路层协议、包格式、流控、QoS、连接管理。而卷 2 又拆成多个分册第 3 分册聚焦的是链路层包格式与传输机制也就是一个 IB 包从发出到被正确解析中间每个 bit 该长什么样、状态机该怎么跳。2025 年 7 月 31 日发布的 Release 2.0 Final 版本意味着这一版已经冻结后续实现者可以拿它当基准做一致性验证。这篇文章不讲泛泛的 IB 科普而是把卷 2 第 3 分册里最影响落地的那几块——包格式、流控信用、VL 仲裁、连接状态机——拆成能对着寄存器手册和抓包工具复现的步骤。适合已经上手过 RDMA 编程、但被底层行为卡住的工程师也适合刚拿到 HCA 手册、想搞清楚每个字段为什么这么设的固件开发者。2. 链路层包格式拆解从 LRH 到 ICRC 的逐字段落地2.1 为什么先啃包格式一个抓包案例引出的字段依赖很多人调 RDMA 性能时习惯先看perfquery的计数器发现port_rcv_errors涨了却不知道从哪查。我一般会先抓一段链路层包用分析仪或者 HCA 自带的诊断模式 dump 原始字节然后对着卷 2 第 3 分册的包格式图逐字段比对。IB 链路层的包不是以太网那种固定偏移它由本地路由头 LRH、全局路由头 GRH可选、基传输头 BTH、扩展传输头 ETH可选、载荷和 ICRC 组成。每个头的长度和字段位置在规范里写得很死但实际实现时最容易翻车的是 VL 字段和 LNH 字段的配合——VL 决定走哪个虚拟通道LNH 决定后面跟的是 GRH 还是直接 BTH。如果 LNH 设错接收端会把 GRH 当 BTH 解析直接丢包并报local_length_error。所以第一步不是写代码而是把包格式的字段依赖关系画成一张表贴在工位上。2.2 用 Python 构造一个最小合法 IB 包并验证字段下面这段代码用 Python 的struct模块手工拼一个不带 GRH 的 IB 包重点是把 LRH 和 BTH 的关键字段按规范填对。你可以把它跑在任意 Linux 机器上输出十六进制字节流再和抓包结果对比。import struct def build_ib_packet(sl, vl, dlid, slid, opcode, pkey, dest_qp, psn): # LRH: 8 bytes # VL(4b) | reserved(4b) | LVer(4b) | SL(4b) | reserved(2b) | LNH(2b) vl_lver (vl 4) | 0x0 # LVer0 for IB sl_res_lnh (sl 4) | (0x0 2) | 0x2 # LNH2 means BTH follows, no GRH lrh struct.pack(BBHHH, vl_lver, sl_res_lnh, dlid, (0x0 12) | (slid 0xFFFF), # reserved SLID 0x0000) # reserved # BTH: 12 bytes # Opcode(8b) | SE(1b) | M(1b) | PadCnt(2b) | Tver(4b) | PKey(16b) | DestQP(24b) | A(1b) | PSN(24b) bth struct.pack(BBHII, opcode, (0x0 7) | (0x0 6) | (0x0 4) | 0x0, # SE0, M0, PadCnt0, Tver0 pkey, (dest_qp 8) | (0x0 7) | ((psn 16) 0xFF), (psn 0xFFFF) 16 | 0x0000) # 简化处理实际PSN占24位 # 载荷4字节对齐的测试数据 payload b\xde\xad\xbe\xef # ICRC实际需要按规范计算这里填0占位 icrc b\x00\x00\x00\x00 return lrh bth payload icrc pkt build_ib_packet(sl0, vl3, dlid0x0001, slid0x0002, opcode0x0A, pkey0xFFFF, dest_qp0x000018, psn0x123456) print(pkt.hex())这段代码的逻辑说明LRH 的第一个字节把 VL 和 LVer 打包第二个字节把 SL、保留位和 LNH 打包。LNH 设为 2 表示后面直接跟 BTH没有 GRH。BTH 里 opcode 用 0x0A 代表 SEND 请求的第一个包PKey 用 0xFFFF 表示默认分区。参数上最容易错的是 PSN 的 24 位对齐——规范里 PSN 跨两个 32 位字低 8 位在高字的高字节剩下 16 位在低字的高 16 位。如果你用现成的 scapy 或者 dpkt 库它们对 IB 的支持不完整还是手工拼最可控。拼完之后用xxd或者 Wireshark 的“Import Hex Dump”功能导入看解析出来的字段和你的预期是否一致。这一步过了再谈流控和状态机才有意义。2.3 参数速查LRH 和 BTH 里最容易被固件写错的五个字段字段位置常见错误值正确做法VLLRH byte0 高4位固定填0按 SL 到 VL 映射表查表通常 SL0 映射 VL0LNHLRH byte1 低2位填1以为有GRH无GRH时填2有GRH时填3PKeyBTH byte4-5填0x0000默认分区用0xFFFF非默认按SM配置DestQPBTH byte8-10只填低16位24位必须填满高8位在byte8PSNBTH byte11-14当成32位整数24位循环回绕时按规范处理这张表是我在调试 HCA 固件时血泪总结出来的。尤其是 LNH 字段很多开源驱动示例里直接写死 0x2但一旦启用 GRH 就会解析错位。DestQP 的 24 位对齐也是经典坑因为大多数网络协议 QP 号不会超过 16 位容易忽略高 8 位。PSN 的回绕行为在规范里有明确的状态机描述如果固件里用简单的 32 位递增跑到 0xFFFFFF 之后会跳到 0x1000000而规范要求回绕到 0。这个错误在长时间压测时才会暴露表现为突然大量丢包。3. 流控信用与 VL 仲裁让链路跑满不丢包的配置逻辑3.1 信用机制的本质接收端缓冲区如何反向控制发送端IB 链路层的流控不是靠丢包重传而是靠信用。每个 VL 独立维护一套信用计数器接收端在初始化时通过交换FlowControl包告诉发送端“我这边每个 VL 有多少个 64 字节单元的缓冲”。发送端每发一个包对应 VL 的信用减一接收端处理完一个包回一个信用包发送端信用加一。信用减到零发送端必须停发该 VL 的包。这套机制的好处是零丢包坏处是如果信用配置太小链路带宽利用率上不去配置太大接收端缓冲区溢出直接翻车。卷 2 第 3 分册里详细定义了信用包的类型FlowControl的 opcode 是 0x0B和信用更新的粒度。实际调优时我一般先看 HCA 手册里每个 VL 的接收缓冲深度然后按信用数 缓冲深度 / 64算一个保守值再逐步加大到链路跑满且不报port_rcv_remote_physical_errors。3.2 用 ibdiagnet 和 perfquery 验证信用配置是否生效光看规范不够得用工具验证。下面这组命令是我在集群上线前必跑的流程用来确认信用配置和 VL 仲裁是否按预期工作。# 1. 查看端口基础状态确认链路已激活 ibstat mlx5_0 # 2. 用 perfquery 读取端口计数器重点看 VL15 丢包和信用相关错误 perfquery -x -C mlx5_0 1 # 3. 用 ibdiagnet 做全链路诊断生成报告 ibdiagnet -o /tmp/ibdiag_out -d 3 -v 3 # 4. 从报告里提取信用和流控相关告警 grep -i flow_control\|credit\|vl15 /tmp/ibdiag_out/ibdiagnet.log逻辑说明ibstat确认物理层和链路层已经 up如果这里显示State: Down后面的信用配置无从谈起。perfquery的-x参数输出扩展计数器-C指定 CA 名称最后的1是端口号。重点看port_xmit_discards和port_rcv_errors如果这两个在压测时增长说明信用或 VL 配置有问题。ibdiagnet是 Mellanox 工具集里的诊断利器-d 3表示诊断深度-v 3是冗余度。跑完之后在日志里搜flow_control如果出现VL15 credit exhausted之类的告警说明管理包占用了太多信用需要调整 VL15 的信用分配。参数上-o指定输出目录-d和-v的范围通常是 1 到 5生产环境用 3 足够。3.3 VL 仲裁表怎么配从 SL 到 VL 的映射与带宽分配VL 仲裁是 IB 里最像“玄学”的部分。规范定义了两种仲裁方式基于优先级的仲裁和基于权重的轮询。实际 HCA 实现里通常用一张 SL 到 VL 的映射表加上每个 VL 的权重寄存器。配置的时候先确定业务流的 SL 值——比如 MPI 集合通信通常用 SL 0存储流量用 SL 1管理流量用 SL 15。然后查 HCA 手册里的映射表寄存器地址把 SL 映射到不同的 VL。权重方面如果两个 VL 共享同一个物理链路权重比就是带宽比。比如 VL0 权重 4VL1 权重 1那么 VL0 能拿到 80% 的带宽。这里有个坑VL15 是保留给管理包的不能映射业务流量而且它的信用是独立的。如果你把业务 SL 映射到 VL15管理包会被饿死链路直接进入VL15 credit exhausted状态表现为ibstat显示链路 up 但所有业务流量超时。我一般会在配置完之后用iblinkinfo确认每个端口的 VL 能力再用ibv_rc_pingpong打流测试不同 SL 的延迟和带宽。4. 连接状态机与 QP 转换从 RESET 到 RTS 的每一步验证4.1 QP 状态机的六个状态和四个转换条件IB 的 Queue Pair 不是建好就能发数据它必须经过状态机转换。卷 2 第 3 分册里定义了 QP 的六个状态RESET、INIT、RTR、RTS、SQD、SQE。实际使用中最核心的是 RESET → INIT → RTR → RTS 这条路径。每一步转换都有严格的参数要求RESET 到 INIT 需要设置 PKey 和端口号INIT 到 RTR 需要设置远端 QP 号和远端 LIDRTR 到 RTS 需要设置发送 PSN 和重传超时。任何一步参数不对转换就会失败返回IBV_WC_REM_ACCESS_ERR或者更模糊的IBV_WC_GENERAL_ERR。我见过太多人卡在 RTR 到 RTS原因是远端 QP 号填错或者 PSN 没对齐。规范里明确写了RTR 状态下 QP 只能接收不能发送RTS 才能发。所以如果你在 RTR 就调ibv_post_send返回的错误是IBV_WC_LOC_QP_OP_ERR而不是超时。4.2 用 rdma_cm 和 libibverbs 写一个状态转换验证程序下面这段 C 代码用 libibverbs 手工做 QP 状态转换每一步都打印返回值方便定位卡在哪。#include infiniband/verbs.h #include stdio.h #include string.h int modify_qp_to_init(struct ibv_qp *qp, uint8_t port, uint16_t pkey) { struct ibv_qp_attr attr; memset(attr, 0, sizeof(attr)); attr.qp_state IBV_QPS_INIT; attr.port_num port; attr.pkey_index 0; attr.qp_access_flags IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_READ; int ret ibv_modify_qp(qp, attr, IBV_QP_STATE | IBV_QP_PKEY_INDEX | IBV_QP_PORT | IBV_QP_ACCESS_FLAGS); printf(INIT ret%d\n, ret); return ret; } int modify_qp_to_rtr(struct ibv_qp *qp, uint32_t dest_qp, uint16_t dlid, uint8_t sgid_idx) { struct ibv_qp_attr attr; memset(attr, 0, sizeof(attr)); attr.qp_state IBV_QPS_RTR; attr.path_mtu IBV_MTU_1024; attr.dest_qp_num dest_qp; attr.rq_psn 0; attr.max_dest_rd_atomic 1; attr.min_rnr_timer 12; attr.ah_attr.is_global 0; attr.ah_attr.dlid dlid; attr.ah_attr.sl 0; attr.ah_attr.src_path_bits 0; attr.ah_attr.port_num 1; int ret ibv_modify_qp(qp, attr, IBV_QP_STATE | IBV_QP_AV | IBV_QP_PATH_MTU | IBV_QP_DEST_QPN | IBV_QP_RQ_PSN | IBV_QP_MAX_DEST_RD_ATOMIC | IBV_QP_MIN_RNR_TIMER); printf(RTR ret%d\n, ret); return ret; } int modify_qp_to_rts(struct ibv_qp *qp, uint32_t sq_psn, uint8_t timeout, uint8_t retry_cnt) { struct ibv_qp_attr attr; memset(attr, 0, sizeof(attr)); attr.qp_state IBV_QPS_RTS; attr.timeout timeout; attr.retry_cnt retry_cnt; attr.rnr_retry 7; attr.sq_psn sq_psn; attr.max_rd_atomic 1; int ret ibv_modify_qp(qp, attr, IBV_QP_STATE | IBV_QP_TIMEOUT | IBV_QP_RETRY_CNT | IBV_QP_RNR_RETRY | IBV_QP_SQ_PSN | IBV_QP_MAX_QP_RD_ATOMIC); printf(RTS ret%d\n, ret); return ret; }逻辑说明modify_qp_to_init设置端口和 PKey 索引访问权限按需加。modify_qp_to_rtr里path_mtu要和远端一致dest_qp_num是远端 QP 号rq_psn是接收 PSN 起点min_rnr_timer是接收端没缓冲时发送端等多久再重试。modify_qp_to_rts里timeout是重传超时指数retry_cnt是重传次数rnr_retry是 RNR 重试次数sq_psn是发送 PSN 起点。参数上timeout一般设 14 到 18对应大约 1 秒到 4 秒retry_cnt设 7 表示重试 7 次rnr_retry设 7 表示无限重试。每一步的返回值必须为 0如果返回 -1用errno看具体错误。常见错误是EINVAL说明某个属性没设或者值超出范围。这个程序跑通之后再上ibv_post_send发数据成功率会高很多。4.3 状态转换失败的排查顺序从本地 QP 到远端 ACK状态转换失败时不要瞎猜。按这个顺序查第一本地 QP 的属性是否完整特别是IBV_QP_AV里的dlid和sl第二远端 QP 是否已经处于 RTR 或 RTS如果远端还在 INIT你转 RTR 会超时第三PKey 是否匹配两端 PKey 不一致会导致 RTR 失败第四MTU 是否一致一端 1024 一端 4096 会在 RTS 后第一个包就丢第五PSN 是否在窗口内如果发送 PSN 和接收 PSN 差太远接收端会静默丢弃。排查工具上ibv_rc_pingpong是最小验证集如果它跑不通你的代码肯定有问题。另外dmesg里会有 HCA 驱动的详细报错比如mlx5_0: QP 0x18 state transition failed后面跟原因码。原因码在卷 2 第 3 分册的附录里有完整列表对着查就行。5. 避坑与常见问题链路层调试中那些让你加班到凌晨的坑5.1 坑一链路显示 ACTIVE 但所有业务流量超时现象ibstat显示State: ActivePhysical state: LinkUp但ibv_rc_pingpong超时perfquery里port_xmit_wait持续增长。原因VL15 信用耗尽。管理包SMP走 VL15如果 VL15 的信用被大量管理查询占满业务包虽然走其他 VL但 QP 状态转换需要管理包交换管理包发不出去转换就卡住。解决用ibdiagnet查 VL15 信用计数如果接近零减少管理查询频率或者调整 HCA 的 VL15 信用寄存器需要厂商工具。另一个原因是 SL 到 VL 映射把业务流量映射到了 VL15改映射表即可。5.2 坑二大包传输时随机丢包小包正常现象MTU 设 4096 时ib_send_bw跑几秒就报port_rcv_errors换成 1024 就正常。原因接收端缓冲区按 64 字节单元分配信用MTU 4096 的一个包消耗 64 个信用如果信用总数不够发送端在发到一半时信用耗尽但接收端还没处理完导致超时重传重传又消耗信用恶性循环。解决查 HCA 手册里每个 VL 的接收缓冲总深度按信用数 深度 / 64算确保信用数大于 MTU/64 的几倍。一般建议信用数至少是最大包消耗的 4 倍。5.3 坑三QP 转换到 RTS 成功但第一个 SEND 就报 REM_ACCESS_ERR现象ibv_modify_qp返回 0但ibv_post_send的完成队列里报IBV_WC_REM_ACCESS_ERR。原因远端 QP 的访问权限没开。RTR 转换时远端的qp_access_flags必须包含IBV_ACCESS_REMOTE_WRITE或IBV_ACCESS_REMOTE_READ否则你的 SEND 到了远端远端检查权限不通过回一个 NAK。解决在远端 QP 转 RTR 时把qp_access_flags设全至少包含IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ。注意IBV_ACCESS_REMOTE_ATOMIC如果不需要就别开开了会增加安全风险。5.4 坑四PSN 回绕导致长时间压测后突然丢包现象压测跑 30 分钟后port_rcv_errors突然暴涨之前一直正常。原因PSN 是 24 位从 0xFFFFFF 回绕到 0 时如果发送端和接收端的回绕处理不一致接收端会认为 PSN 乱序丢弃所有包。规范里要求回绕时按模 2^24 计算但有些固件实现用 32 位比较导致回绕后差值巨大。解决在固件或驱动里显式处理回绕用(psn - expected_psn) 0xFFFFFF来判断顺序而不是直接比较大小。测试时可以用脚本把 PSN 初始值设到 0xFFFF00跑几分钟就能触发回绕。5.5 坑五ibdiagnet 报告正常但应用层延迟抖动大现象ibdiagnet所有检查项通过但 MPI 程序延迟抖动超过 100 微秒。原因VL 仲裁权重配置不合理高优先级 VL 饿死低优先级 VL导致低优先级流量突发时延迟飙升。解决用perfquery看每个 VL 的发送字节数如果某个 VL 的字节数远低于权重比例说明仲裁器没按预期工作。调整权重寄存器让权重比接近实际流量比。另外检查 SL 到 VL 映射是否把延迟敏感的流量映射到了高优先级 VL。6. 进阶技巧用规范附录的伪代码验证你的状态机实现卷 2 第 3 分册的附录里有一组状态机伪代码很多人直接跳过觉得是“参考实现”。我一开始也这么想直到有一次 QP 转换在特定时序下失败查了三天才发现是状态机里一个“先检查后执行”的顺序问题。规范伪代码里明确写了在 RTR 到 RTS 转换时必须先更新发送 PSN再使能发送队列如果反过来第一个包的 PSN 会用旧值导致接收端认为乱序。这个细节在正文里只是一句话但在附录伪代码里是显式的两步。所以我的习惯是任何状态机实现先照着附录伪代码逐行翻译成 Python 或者 C 的断言跑一遍单元测试再移植到固件。下面这个表格是我整理的附录里最容易被忽略的三个时序点。转换规范要求顺序常见错误顺序后果INIT→RTR先设 RQ PSN再设 dest_qp先设 dest_qpRQ PSN 用默认值接收窗口错位RTR→RTS先更新 SQ PSN再使能 SQ先使能 SQ第一个包 PSN 旧值远端丢包RTS→SQD先排空 SQ再改状态直接改状态未完成的 WQE 丢失完成队列无事件验证方法上我一般会写一个 Python 脚本把附录伪代码里的每个状态和转换条件抽成字典然后用随机事件序列跑 10000 次看是否出现死锁或者非法状态。这个脚本不需要连硬件纯逻辑验证但能抓住 80% 的状态机实现错误。剩下的 20% 是硬件时序问题只能上逻辑分析仪或者 HCA 的诊断模式抓波形。最后说一个我自己的教训不要相信“这个版本和上一版差不多”这种话。Release 2.0 Final 和之前的草案之间光流控信用包的格式就改了两次如果你拿旧代码直接跑会在信用更新时解析错位表现为链路时断时续。每次升级规范版本先把附录的变更列表过一遍再动代码。希望帮到你。本文还有配套的精品资源点击获取