简介这是InfiniBand Trade Association发布的《InfiniBand Architecture Specification Volume 1 Release 1.6》官方规范文档主要面向HPC、企业数据中心、存储网络领域的架构师、网络工程师及RDMA应用开发者用于解决高性能互连中的吞吐、延迟与协议一致性问题。压缩包内为单个PDF文件共1个文件大小约13.74MB便于完整保存与检索阅读。该规范详细记录了自2000年1.0版以来至2022年7月的全部修订历史并重点阐述1.6版新增特性支持大型radix A交换机、扩展传输通道操作码、内存放置的VERIFY操作等。同时覆盖RDMA直接内存访问、QoS服务质量、RoCE/虚拟化等核心内容并附有完整法律与专利声明。读者可从中获得IBTA协议的体系化知识理解不同硬件与软件组件的协同方式。目前已有187人学习适合希望从协议层深入掌握InfiniBand网络设计、配置与故障排查的进阶技术人员。1. 深夜排障时没人帮你读规范Volume 1 Release 1.6 到底管到哪一层凌晨两点HPC 集群一条 200G 链路明明ibstat显示 Active吞吐却只有预期的一半。同事丢过来一句回去翻 InfiniBand Architecture Specification Volume 1 Release 1.6。这时候你手上这份规范不是物理层手册也不管线缆和连接器——它规定的是 InfiniBand 的链路层、网络层、传输层以及通道适配器 CA 必须暴露给软件的行为。驱动要按它对齐 QP 状态机固件要按它实现报文头字段交换机要按它做 SL 到 VL 的调度。我按自己落地 HDR 项目、写自研网卡驱动的经验把这份 Volume 1 拆成「怎么读、哪些参数要背、哪几个坑值得记」。适合正在写驱动、调集群、给自研设备做协议符合性验证的人。2. 从 1.5 到 1.6先搞清这份 Architecture Specification 改了什么再动手2.1 Release 1.6 的业界位置HDR 时代默认对齐的协议版本你打开任何一款主流 HDR 网卡的驱动 release note大概率能看到一句话compliant with IBTA architecture specification Release 1.6。这不是厂商随便写的而是因为 1.6 是 HDR 200Gb/s 时代被引用最多的稳定版本。做适配的时候我们的习惯是新项目默认对齐 1.6只在遇到老设备或者追 NDR 新特性时才去翻更早或更新的文档。常见引用版本大致关联的技术代际我做适配时的用法1.2.1SDR/DDR/QDR 初代生态老设备兼容性排查时对照1.3QDR 40Gb/s 生态整理链路层老参数溯源1.4EDR 100Gb/s老固件 EDR 链路问题对照1.5HDR 200Gb/s 基础定义链路层速率与信令参数1.6HDR 时代勘误与传输层增强新项目默认对齐版本后续版本NDR 相关新增做 NDR 项目再追读增补这个表格不是教科书式分类而是我实际查问题时的心智地图。Release 1.6 最大的价值在于它把 1.5 里 HDR 引入后产生的一批模糊表述做了收敛比如某些头部字段的保留位约束、拥塞通知报文的格式歧义都在 1.6 里被订正。如果你手头项目是从 1.5 的老代码迁移过来的首先要做的不是读全文而是对照两个版本的修订记录。2.2 修订记录怎么读区分「新增功能」和「勘误订正」IBTA 的规范在正文之前会有一段版本变更说明1.6 这一版把自 1.5 以来的改动逐条列出来。我的读法很简单拿一支笔把每条改动标成三类——A 是新增能力B 是勘误订正C 是纯措辞修订。只有 A 和 B 需要动代码C 可以直接跳过。标记含义要不要改实现A新增功能或新增字段需要评估是否支持B对旧文本的纠错或收紧很可能要改风险最高C措辞澄清行为不变不改但读一遍防误解血泪经验是B 类改动最容易翻车。比如 1.5 里某个重传字段写得模棱两可厂商 A 按一种解释实现厂商 B 按另一种解释实现1.6 把规则定死了。如果你只对着 1.5 开发互操作测试时就会眼睁睁看着对端丢包。所以我一般会建议先翻到修订记录把 B 类条目摘出来做成一张 Excel逐条问自己「我现在的代码是哪一种解释」。2.3 Volume 1 的三层骨架Link、Network、Transport 各管哪段Volume 1 的主体按层次组织这也是读它的主线。链路层管 LID 路由、SL服务等级、VL虚拟通道和两种 CRC——ICRC 覆盖不变字段VCRC 覆盖可变字段用于检测头部被改。网络层管 GRH 和 GIDGID 本质是 128 位子网前缀 64 位加接口 GUID 64 位所以抓包看到 GID 以fe80开头时别奇怪那是链路本地子网前缀。传输层管 QP 类型、BTH、应答机制、超时重传和原子操作这是驱动开发最常驻的区域。很多新人会去物理层手册里找 LID 的定义找半天找不到——LID 属于链路层就在 Volume 1。去 Volume 2 翻只会浪费时间。记一句话Volume 1 决定报文怎么组织、QP 怎么走状态机、错误怎么上报Volume 2 决定信号怎么上线缆Volume 3 决定子网怎么被管理。你排查 99% 的驱动问题主战场都在 Volume 1。3. 把规范翻译成驱动行为QP 迁移、报文头与 Verbs 的对应关系3.1 QP 状态机从 RESET 到 RTS每个迁移点规范要求了什么QPQueue Pair是 InfiniBand 里最核心的对象规范对它的状态迁移写得非常死。RESET 到 INIT只允许初始化发送侧INIT 到 RTR要填对端 QPN、路径参数、MTU 和超时值RTR 到 RTS才能开始正常收发。每个迁移点都是一次modify_qp操作驱动里对应ibv_modify_qp的调用。状态迁移必须设置的属性我常见到有人漏掉的RESET → INITP_Key 索引、Q_KeyQ_Key 与对端不一致INIT → RTR对端 QPN、路径 MTU、RTR PSN路径 MTU 忘了协商RTR → RTS发送 PSN、重传次数、RNR 次数ack 超时字段填了 0最容易踩的坑是 RTR 阶段的路径 MTU。规范要求接收端在 RTR 时就得知道自己能收多大包不是你发的时候才定。很多人只在对端 QPN 上花了心思MTU 随便填个 4096结果对端交换机只支持 2048跑到一半掉包。规范在这里是明确写了「取路径最小值」但驱动不会替你算得靠子网管理器下发的报文厂参数来定。3.2 报文怎么被套上 LRH、GRH、BTH抓包时按这几个字段定位数据包在线上不是裸的 payload而是层层套头。LRH 8 字节里面最关键的是 DLID、SL、VL 和 LNHDLID 决定下一跳送谁SL 决定服务等级交换机把 SL 映射成 VL 做实际调度。GRH 40 字节承载 SGID/DGIDUD 类型强制要求有 GRHRC/UC 在跨子网时才必须带。BTH 12 字节包含 OpCode、P_Key、24 位 PSN 和应答请求位。头部典型长度关键字段排查作用LRH8 字节DLID、SL、VL、LNH判断路由和优先级GRH40 字节SGID、DGID判断源/目的地址BTH12 字节OpCode、P_Key、PSN判断操作类型和包序抓包的时候很多人只看 payload不看头。我一般先看 BTH 的 OpCode 是不是预期的 RDMA WRITE再看 PSN 是否连续。PSN 断层说明有丢包在走重传P_Key 对不上则直接能看到错误状态。尾部还有 ICRC 和 VCRC 各 4 字节前者保头部不变字段后者保可变字段抓包工具里看到 CRC 错先怀疑中间有交换机改了 SL 或 VL。3.3 从 ibv_create_qp 回看规范你写的那行 API 背后是哪几页对写 Linux 驱动或用户态程序的人来说规范不会直接教你怎么调ibv_create_qp但你知道它背后在干什么。ibv_create_qp创建一个 QP 上下文对应规范里对 QP 对象属性的定义ibv_post_send提交一个工作请求会被翻译成特定 OpCode 的 BTH 包。Verbs 层调用BTH 里的 OpCode实际线上行为IBV_WR_SENDSend Only发送给对端已提交的接收 WRIBV_WR_RDMA_WRITERDMA WRITE直接写对端内存不消耗对端 WRIBV_WR_RDMA_READRDMA READ从对端内存读回本地IBV_WR_ATOMIC_CMP_AND_SWPCompare Swap对端地址做 8 字节原子比较交换这个映射关系的意义在于排查如果你post_send之后对端没反应先想 BTH OpCode 发出去没有再想对端有没有对应的接收缓冲区。RDMA WRITE 不消耗对端 WR这是规范层就定死的不是驱动实现差异。看懂了这层你就不会再问「为什么 RDMA WRITE 对端程序必须提前 post 很多收包请求」这种问题了。4. 按 1.6 参数表做适配MTU、超时、P_Key、SL、拥塞、MR 六个必查项4.1 MTU 协商字段 5 等于 4096路径最小值说了算链路层 MTU 的取值由子网管理器下发的端口属性决定最大是 4096 字节字段编码里 5 对应 40961 到 4 分别对应 256 到 2048。QP 的路径 MTU 是所有经过链路的最小值不是你自己端口的最大值。MTU 字段值大小典型场景1256 字节重负载多跳网老交换机2512 字节混合设备兼容31024 字节常规 HPC 部署42048 字节RoCE 场景常用54096 字节同子网直连 HDR 常态排查时用smpquery portinfo逐跳看mtu字段而不是只看本端。曾经有个客户链路时不时掉包查了半天是中间一台老交换机最大支持 2048本端配了 4096。规范没写错是没人逐跳核对。4.2 Ack 超时公式4.096us×2^n别直接抄别人的「20」传输层的 ack 超时字段是 0 到 31 的编码值实际超时时间用公式4.096us * 2^n计算。我见过大量项目直接抄默认值 20但 20 算出来约 4.3 秒对某些低延迟场景太宽松对长距离重传场景可能又太紧。# 把 QP timeout 编码换算成实际超时再决定填多少 python3 - PY for n in (12, 14, 16, 18, 20): us 4.096 * (2 ** n) print(ftimeout{n:2d} - {us:12.0f} us {us/1e6:7.3f} s) PY输出里timeout16大约是 268mstimeout18约 1.07stimeout20约 4.3s。我的建议是机房内短链路从 14 到 16 试起跨机房长距离再往上加。重传次数和 RNR 重试次数是独立字段别混在一起调。4.3 P_Key 0xFFFF 与 0x7FFF能 ping 通不等于能 RDMAP_Key 是 16 位分区键最高位表示成员类型1 是 full member0 是 limited member。默认分区里full member 是 0xFFFFlimited member 是 0x7FFF。QP 创建时绑定一个 P_Key 索引数据包 BTH 里带的 P_Key 得和 QP 上下文一致才能被接收。P_Key 值类型权限含义0xFFFFfull member默认分区完整成员权限0x7FFFlimited member受限成员权限用户自定义按分区表需要 SM 统一下发注意ibping这类工具走的是 SMP 管理通道对 P_Key 的校验和普通数据 QP 不完全一样。所以经常出现「ping 通但 RDMA 拒绝」的怪象这不是玄学是 P_Key 校验发生在不同的对象上。4.4 SL 与 VL 的映射QoS 的表由子网管理器维护服务等级 SL 是 4 位0 到 15表示端到端的服务要求VL 是虚拟通道物理链路上实际有几条收发的通道。交换机和 CA 里有一张 SL 到 VL 的映射表由 SM 统一下发不是驱动自己拍的。配置对象谁管理常见坑SL 值发送端 QP/GRH 字段对端 SL 不一致SL2VL 表子网管理器交换机没同步表项VL 数端口属性配置了 4 VL 但硬件只支持 2调 QoS 时先确认整条路径 SL 相同再看交换机 SL2VL 映射。把 SL 当 IP DSCP 用没问题但记住这张表必须由 SM 下发手工改交换机配置会在重扫之后被覆盖。4.5 FECN/BECN 与拥塞控制规范给开关不给完整算法拥塞通知在链路层到传输层都有痕迹交换机发现拥塞会在包里置 FECN前向拥塞通知接收端收到后回 BECN后向拥塞通知发送端据此降速。1.6 里对这两个标志的格式和转发要求有明确定义但完整的降速算法比如 DCQCN 的速率步长、恢复时机属于实现层的东西。对象规范层定义实现层你决定FECN 标志头部位交换机会置位是否解析并上报BECN 报文格式与路由要求生成策略与优先级速率调整约束上限与最小间隔具体加减速曲线做自研设备时最容易犯的错是以为读了规范就能实现拥塞控制。规范只是把通知机制定死了算法还得你自己在 CA 里出。先保证 FECN/BECN 标记和上报路径正确再谈调优。4.6 MR 的 L_Key 与 R_Key远程访问权限的颗粒度在哪内存注册MR之后会得到两个键L_Key 给本地 DMA 用R_Key 给对端远程访问用。规范定义了 MR 的访问权限组合本地写、远程读、远程写、远程原子操作是分开的位。权限位允许的操作我常用的配置IBV_ACCESS_LOCAL_WRITE本地设备写内存几乎所有 MR 都开IBV_ACCESS_REMOTE_WRITE对端发起 RDMA WRITE只给需要被写的内存IBV_ACCESS_REMOTE_READ对端发起 RDMA READ只读数据缓冲IBV_ACCESS_REMOTE_ATOMIC对端原子操作只在锁场景开R_Key 不是你自己用的是贴好信封写给对端的。对端拿这个 R_Key 和内存地址发 RDMA WRITE本地 CA 校验通过才落盘。权限开大了怕被越权写开小了业务链路不通。我一般坚持最小权限原则远程写的 MR 单独建不和读缓冲混在一起。5. 避坑六条从「读懂了规范」到「实现翻车」的记录5.1 现象SMP 请求找不到对端双端口 CA 的固件初始化时两个端口拿到的 LID 一样了ibping直接超时。原因LID 由 SM 按端口分配base LID 与 LMC 字段决定了一个端口占用几个 LID如果固件初始化时序里把两个端口的 LID 寄存器写成同一个值管理报文就回错「人」。解决停掉 SM重扫整个子网再用ibstat核对两个端口的 LID至少在代码里加一条启动断言双端口 LID 必须不同。5.2 现象MTU 协商到 4096 之后偶发丢包ibstat显示 active MTU 4096ib_send_bw跑小包没问题跑到最大包就掉点。原因路径上某台交换机实际只支持 2048但它的端口属性字段被误配成了 4096导致它转发 4096 包时静默丢弃。解决不要只信本端ibv_devinfo用smpquery portinfo逐跳抓mtu找到最小项重新下发。这条实践后来被我写进了团队 checklist。5.3 现象RC 正常、UD 不通怀疑对端驱动有问题RC 能通信UD 一post_send就报错。原因把 GRH 当可选头处理了UD 类型强制要求 GRH而本地发送缓冲区里根本没填 SGID/DGID。解决抓包看头部前 40 字节是不是 GRH如果是就直接看 SGID 和 DGID 里子网前缀是否一致。同子网时 GID 前缀都是fe80::跨子网就是真实路由前缀这一步经常能揪出配置错误。5.4 现象对端偶发 RNR 唤醒重传次数耗尽直接掉链应用偶发慢抓了很久发现对端回的是 RNR NAK发送端重试几次后彻底放弃。原因接收端队列深度不够是直接原因但更深层是 ack 超时和重试字段是猜的没有按4.096us×2^n算过路径时延。解决把超时字段按公式重算同时看硬件计数器里的rnr_nak_received先加接收队列深度再调超时。别一上来就改重传次数那只是延长痛苦。5.5 现象P_Key 能 ping 通但 RDMA 被拒绝两边同属一个分区ibping也通但建 QP 时ibv_modify_qp返回EINVAL。原因SMP 管理通道对 P_Key 校验宽数据 QP 的 P_Key 是包到 BTH 之后逐包校验的两边 QP 上下文绑定的 P_Key 索引不同一个绑 0xFFFF另一个绑 0x7FFF。解决查/sys/class/infiniband/mlx5_0/ports/*/pkeys把两边的索引和键值列出来对齐再用smpquery partitions看 SM 里分区成员列表。这个坑在我见过的一半互操作事故里都出现过先查它。6. 不花钱验证你读懂了 1.6三个自检步骤与核对清单6.1 用 ibv_devinfo 和 smpquery 对照端口参数在任意一台装了 InfiniBand 驱动的机器上都能做。先看驱动视角再看子网管理器视角两者一致说明你没有读错规范ibv_devinfo -v | grep -E active_mtu|link_layer|port_lid|active_speed smpquery portinfo 1 | grep -E mtu|lid|physicalstate我习惯对比 active_speed 里的 HDR 字样、port_lid、active_mtu 和 smpquery 返回的物理状态。对不上就肯定有一端在按错误版本解释字段。6.2 用 perftest 观察重传行为跑一轮ib_send_bw同时用perftest里的统计或者ibstat计数器看重传率。这里有个小技巧故意把 QP 超时字段调小到编码 8观察丢包是否显著增加如果增加说明你对超时公式的理解和实际行为对得上。调完记得改回来。这就是把规范条款变成可观察信号的办法比背公式有用。6.3 做一张三列核对表十分钟就能完成每次排障后我都填一张小表左边是规范里抄来的字段中间是驱动读出的值右边是 SM 下发的值。字段规范要求1.6驱动读出SM 下发MTU取路径最小值40964096LIDbase LIDMC 预留0x120x12P_Key0xFFFF/0x7FFF0xFFFF0xFFFFSL0-15 保持一致00timeout4.096us×2^n16—这不是形式主义。填到第三次你就会发现绝大多数翻车都发生在 P_Key 和 MTU 两行。我现在的习惯是改任何 CA 配置之前先截一张三列核对表的图等改完再截一张两相对比就知道自己动了什么、规范是否允许。这套流程帮我挡了不少本可以避免的「后半夜故障」。希望帮到你。本文还有配套的精品资源点击获取