简介：这是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.1 | SDR/DDR/QDR 初代生态 | 老设备兼容性排查时对照 |
| 1.3 | QDR 40Gb/s 生态整理 | 链路层老参数溯源 |
| 1.4 | EDR 100Gb/s | 老固件 EDR 链路问题对照 |
| 1.5 | HDR 200Gb/s 基础定义 | 链路层速率与信令参数 |
| 1.6 | HDR 时代勘误与传输层增强 | 新项目默认对齐版本 |
| 后续版本 | 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 和 GID，GID 本质是 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：每个迁移点规范要求了什么
QP（Queue Pair）是 InfiniBand 里最核心的对象，规范对它的状态迁移写得非常死。RESET 到 INIT，只允许初始化发送侧；INIT 到 RTR，要填对端 QPN、路径参数、MTU 和超时值；RTR 到 RTS，才能开始正常收发。每个迁移点都是一次modify_qp操作，驱动里对应ibv_modify_qp的调用。
| 状态迁移 | 必须设置的属性 | 我常见到有人漏掉的 |
|---|---|---|
| RESET → INIT | P_Key 索引、Q_Key | Q_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 和 LNH：DLID 决定下一跳送谁，SL 决定服务等级，交换机把 SL 映射成 VL 做实际调度。GRH 40 字节，承载 SGID/DGID，UD 类型强制要求有 GRH，RC/UC 在跨子网时才必须带。BTH 12 字节，包含 OpCode、P_Key、24 位 PSN 和应答请求位。
| 头部 | 典型长度 | 关键字段 | 排查作用 |
|---|---|---|---|
| LRH | 8 字节 | DLID、SL、VL、LNH | 判断路由和优先级 |
| GRH | 40 字节 | SGID、DGID | 判断源/目的地址 |
| BTH | 12 字节 | 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_SEND | Send Only | 发送给对端已提交的接收 WR |
IBV_WR_RDMA_WRITE | RDMA WRITE | 直接写对端内存，不消耗对端 WR |
IBV_WR_RDMA_READ | RDMA READ | 从对端内存读回本地 |
IBV_WR_ATOMIC_CMP_AND_SWP | Compare 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 对应 4096，1 到 4 分别对应 256 到 2048。QP 的路径 MTU 是所有经过链路的最小值，不是你自己端口的最大值。
| MTU 字段值 | 大小 | 典型场景 |
|---|---|---|
| 1 | 256 字节 | 重负载多跳网，老交换机 |
| 2 | 512 字节 | 混合设备兼容 |
| 3 | 1024 字节 | 常规 HPC 部署 |
| 4 | 2048 字节 | RoCE 场景常用 |
| 5 | 4096 字节 | 同子网直连 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(f"timeout={n:2d} -> {us:12.0f} us = {us/1e6:7.3f} s") PY输出里timeout=16大约是 268ms，timeout=18约 1.07s，timeout=20约 4.3s。我的建议是：机房内短链路从 14 到 16 试起，跨机房长距离再往上加。重传次数和 RNR 重试次数是独立字段，别混在一起调。
4.3 P_Key 0xFFFF 与 0x7FFF：能 ping 通不等于能 RDMA
P_Key 是 16 位分区键，最高位表示成员类型：1 是 full member，0 是 limited member。默认分区里，full member 是 0xFFFF，limited member 是 0x7FFF。QP 创建时绑定一个 P_Key 索引，数据包 BTH 里带的 P_Key 得和 QP 上下文一致才能被接收。
| P_Key 值 | 类型 | 权限含义 |
|---|---|---|
| 0xFFFF | full member（默认分区） | 完整成员权限 |
| 0x7FFF | limited 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 4096，ib_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 | 取路径最小值 | 4096 | 4096 |
| LID | base LID+MC 预留 | 0x12 | 0x12 |
| P_Key | 0xFFFF/0x7FFF | 0xFFFF | 0xFFFF |
| SL | 0-15 保持一致 | 0 | 0 |
| timeout | 4.096us×2^n | 16 | — |
这不是形式主义。填到第三次，你就会发现绝大多数翻车都发生在 P_Key 和 MTU 两行。我现在的习惯是改任何 CA 配置之前先截一张三列核对表的图，等改完再截一张，两相对比就知道自己动了什么、规范是否允许。这套流程帮我挡了不少本可以避免的「后半夜故障」。希望帮到你。
本文还有配套的精品资源，点击获取
