简介InfiniBand架构规范第2卷物理规格2.0最终版由IBTA于2025年7月31日发布面向从事高性能计算、数据中心网络及RDMA互连的工程师与研究人员。该规范完整定义了物理层标准涵盖电缆、连接器、接口以及电气和信号规范确保不同厂商设备在数据中心环境中兼容高效运行。文档保留了自1999年以来的修订历史包含从1.0到1.6版本的功能演进如FDR/EDR/HDR/NDR/XDR信号速率、64b/66b编码、前向纠错FEC、QSFP/OSFP可插拔接口等并标注了废弃特性与合规性声明转移情况。本资源为单个PDF文件容量约7.07MB轻量便携便于查阅与打印。已有238人学习下载适合需要参考官方物理层定义以进行设备开发、测试互操作或协议研究的专业人士。内容提取自扫描图像个别文字可能存在识别误差阅读时需结合上下文判断。1. 一份等了三年的 IB 规范Vol 2 Release 2.0 到手后先看哪几页做 InfiniBand 交换机和 RDMA 网卡调测的人大概都受过同一份罪抓包里明明看到 LRH 和 BTH却因为不清楚字段位宽解析结果跟对端对不上配置 QoS 时 SL 和 VL 的映射关系含糊业务流量就是不走预期路径。2025 年 7 月 31 日IBTA 放出了 IB Specification Vol 2 Release 2.0 最终版距离上一版修订已经过了相当长一段时间这份文档把链路层、网络层、传输层的规范重新收拢了一遍。对做驱动、固件、交换机开发和存储网络运维的从业者来说它不是一份需要从头读到尾的教科书而是一本遇到问题再翻的“对照手册”——前提是你知道去哪里翻。2. IB 三卷体系里 Vol 2 的边界从物理层到传输层你在哪一卷做工2.1 三卷体例与 Vol 2 的职责卷一讲思想卷二给实现IBTA 的规范体系按功能拆成多卷最常见的划分是Vol 1 讲架构与概述Vol 2 覆盖物理层、链路层、网络层、传输层Vol 3 讲管理模块和通用管理接口。对做报文解析、链路状态机、路由转发的人Vol 2 是实际工作量最大的一卷Vol 1 里只会告诉你 “InfiniBand 网络由子网管理器SM统一管理”但 SM 怎么跟交换机交互、链路怎么训练、报文头字段排布全部落到 Vol 2 里定义。一个常见的误区是拿 Vol 1 的架构图去对应报文解析发现对不上。原因很简单Vol 1 给的是逻辑分层和交互流程Vol 2 给的是线上格式。比如报文头里 LRHLocal Route Header的 VL 字段占 4 bitSL 占 6 bitLVer 占 4 bit——这类位宽信息 Vol 1 不会写这么细即使写了也会注明“详见 Vol 2”。所以拿到 Release 2.0 后先默认把 Vol 2 当作协议细节的权威来源不要拿别的二次文档当依据。2.2 为什么 Vol 2 比 Vol 1 对 RDMA 开发者更关键链路层与包格式RDMA 的实际收发路径上数据要经过多次头封装与解封装。发送侧从传输层产生 BTHBase Transport Header加上网络层的 GRHGlobal Route Header再加链路层的 LRH然后才交给物理层编码。接收侧顺序反过来。这套过程里绝大多数可供调参的字段都定义在 Vol 2 的各章包括但没有不限于LRH 里的 DLID 和 SL前者决定报文在子网内怎么转发后者跟服务等级绑定BTH 里的 OpCode、PSN、QPN分别对应操作类型、包序号和队列对编号分组的 MTU 上限以及 SL 与 VL 的仲裁映射关系。做 RDMA 网卡驱动时如果只对着内核的include/rdma/ib_pack.h写解析很容易忽略规范里对保留字段的定义变化。这次 Release 2.0 的最终版里链路层部分对错误检测机制的解释做了重新整理比如 VCRC 与 ICRC 的覆盖范围说明文字比老版本更明确。开发者直接读那几页能省掉不少向硬件 FAE 反复确认的时间。2.3 物理层在本卷中的存在感链路训练与状态切换很多人一提 InfiniBand 就看到链路层和传输层忽略物理层也编在 Vol 2 里。链路是否能建立、从 LinkUp 到 Active 需要多久、降速协商发生在哪个阶段这部分状态机和参数就在本卷靠前的章节。做交换机端口诊断时show interface看到的 “LinkUp: 4x” 这类信息底层依据就是物理层链路训练的结果。链路训练里的恢复时间参数、信号丢失阈值、重试次数硬件工程师需要查表软件工程师至少要理解状态切换的触发条件否则排查 “端口起来但 ping 不通” 会毫无头绪。3. 把 PDF 当 API 文档读三张表定位 LRH、BTH 与 QoS 参数3.1 先读变更记录与目录结构Release 2.0 的修订重点拿到这份最终版 PDF我一般不会从第 1 页开始读。先翻到文档前面的修订历史Revision History看从上次修订到这次哪些章节被新增或重写。Release 2.0 最终版里链路层和网络层的修订条目明显多于物理层而传输层对 RDMA Read/Write 操作的包格式描述也做了部分澄清。紧接着打开书签目录把章节号和你手头的业务模块做个一一对应业务场景优先阅读章节范围交换机转发与链路诊断物理层链路训练、链路层 LRH 解析RDMA 网卡驱动开发网络层 GRH、传输层 BTH/RETH 格式QoS 与拥塞控制链路层 SL-to-VL 映射、仲裁表子网管理器开发链路层 MAD 封装、Vol 3 协同章节这一步做完你大概知道自己要精读哪些部分其余章节留着查表。读规范最忌讳从头啃到尾它不是小说是字典。3.2 关键报文头字段速查LRH 与 BTH 的位宽和用途报文解析类的开发任务最常用的信息集中在 LRH 和 BTH 两个头。下表根据 Vol 2 Release 2.0 的定义整理可直接用作开发时的速查字段所属头部位宽含义与注意点VLLRH4 bit虚拟通道编号决定报文进入哪个 VL 队列SLLRH6 bit服务等级与 VL 仲裁映射相关LVerLRH4 bit链路层版本号通常为 0DLIDLRH16 bit目的局部 ID单播和多播范围不同OpCodeBTH8 bit操作码区分 Send/Write/Read/AtomicPSNBTH24 bit包序号用于排序和重传判断QPNBTH24 bit队列对编号目标 QPTVerBTH8 bit传输层版本号读这张表时特别要注意位宽的单位不是字节而是 bit很多第一次写解析器的人会在htonl字节序转换时把字段位置搞错。不管你怎么定义结构体线上格式始终以这张表的位宽为准代码里的#pragma pack和位域定义都只是为了贴近这个物理排布。3.3 QoS 与 MTU 参数SL、VL、MTU 三者如何联动Vol 2 在链路层部分给出了 MTU 的枚举值和对应字节数从 256 字节到 4KB 不等具体对应关系在规范里的一个枚举表中。实现队列配置时QP 的 MTU 上限要和端口实际配置匹配否则报文可能在链路上被丢弃。SL 与 VL 的映射在很多设计中并不需要硬件工程师干预因为默认配置通常是 SLVVL但一旦做拥塞控制或隔离就得仔细看仲裁表的内容。规范在 QoS 章节给出的是机制和字段定义实际策略由子网管理器下发。我一般建议读这段时把“机制”和“策略”分开机制看 Vol 2策略看 SM 的配置文件别混在一起。4. 从规范到交换机与代码链路训练状态机与报文头常量提取4.1 交换机端口视角下的 Vol 2链路训练与状态机做 IB 交换机时链路训练状态机是最容易出问题的地方。交换机端口上电后物理层要经历多个子状态初始化、训练、交换链路参数、进入 LinkUp。任何一个状态超时都会导致端口一直停留在某个中间态。Vol 2 的物理层章节会给出每个状态的超时时间和重试次数这些参数最终映射到交换机 SDK 的寄存器配置里。调试时如果发现端口 LinkUp 后偶尔闪断先别急着怀疑光模块回头核对状态机里的降速协商逻辑是否符合规范推荐的超时窗口。常见做法是将规范里的状态转移条件整理成一张表格然后对应到代码里的switch (state)分支。状态名字符串在 SDK 里可能是PORT_STATE_TRAINING这类宏其底层数值定义要与 Vol 2 的表一致。有一次我发现某个平台把LinkUp和Active两个状态当成一个值上报查了规范才发现前者只是物理就绪后者还要求逻辑层同步完成这个差别让监控系统误报了半小时的端口状态。4.2 把规范字段映射成代码报文头结构体与常量提取以 LRH 为例用位域结构体描述头部排布是驱动开发里最常见的写法。C 语言代码可以这样定义#include stdint.h #pragma pack(push, 1) struct ib_lrh { uint8_t vl_sl_ver; /* bit 0-3: VL, bit 4-9: SL, bit 10-13: LVer */ uint16_t dlid; /* 目的局部 ID */ uint16_t slid; /* 源局部 ID */ uint8_t pkey_msb; /* P_Key 高 8 位 */ uint8_t pkey_lsb; /* P_Key 低 8 位 */ }; #pragma pack(pop)这里把 VL、SL、LVer 合并进一个字节是因为它们在线上格式里连续排布拆开定义反而容易在字节序转换时出错。使用这个结构体时注意读出来之后要先做位运算还原uint8_t raw lrh-vl_sl_ver; int vl raw 0x0F; /* bit 0-3 */ int sl (raw 4) 0x3F; /* bit 4-9跨字节边界实际需按完整 16bit 处理 */实际上 SL 有 6 bit会跨越字节边界上面代码里仅用 8 bit 做示意。要完全精确就得从网络字节序流里按位切。这事儿的正经做法是写一个位域提取函数而不是依赖结构体对齐。还有一个更快的办法从 Vol 2 的 PDF 里把字段定义表格手工整理成一份 JSON再根据字段名和位宽自动生成解析代码。下面这段 Python 脚本可以帮你把录制好的字段定义转成 C 语言位域声明避免手写出错import json fields [ {name: VL, bits: 4}, {name: SL, bits: 6}, {name: LVer, bits: 4}, ] bit_offset 0 for f in fields: start bit_offset end bit_offset f[bits] - 1 print(f// {f[name]}: bit {start}..{end}) bit_offset f[bits]脚本的思路是记录每个字段的起始位再把结果打印出来供你核对。这样从规范表格到代码定义中间少了一步人肉换算出错的概率低很多。如果你写的是 Rust 或者 Verilog这个思路同样成立只是输出格式不同。4.3 网络层与传输层的落地GRH 与 BTH 的处理边界读 Vol 2 时你会发现传输层给的是 BTH 之后的报文格式并不涉及 RDMA 语义比如 Send 和 Write 的操作码定义在这里但具体怎么写内存、怎么产生完成事件属于驱动和硬件交互的范畴。因此做软硬件接口的设计师要同时看两份资料Vol 2 管线上格式厂商的 HW Manual 管门铃寄存器怎么写。经常有人把两者混为一谈出了 bug 也不知道是驱动没按手册写寄存器还是报文头跟规范不一致。处理 BTH 时有个容易忽略的点OpCode 的值域里包含RDMA_READ_REQUEST和RDMA_READ_RESPONSE但响应报文里还会带 AETHACK Extended Transport Header它的字段定义也在本卷。写抓包工具时如果不解析 AETHRDMA Read 的完成时间永远对不上排查性能问题会多绕很多弯路。5. 避坑记录读 IB 规范时五个最容易翻车的细节5.1 字节序问题结构体位域与网络序不一致现象抓包工具解析的 DLID 和驱动日志里打印的 DLID 差了一大截看起来毫无规律。原因LRH 里的字段按网络字节序排布而 x86 上结构体默认按小端解释。如果你直接把报文指针强转成结构体又不做字节序转换多字节字段的高低位就是反的。解决解析前先明确每个多字节字段都需要ntohs或ntohl。建议在驱动里统一收口一个ib_parse_lrh()函数所有字段解析都走它不要各写各的。从那以后我每次新加一个报文头解析都会先检查有没有走统一的字节序入口。5.2 保留字段未清零导致解析错位现象同一份报文有些端口解析正常有些端口解析错误而且错误总是集中在某些固定厂商的设备上。原因发送端把保留字段填了任意值接收端固件又严格按规范要求把保留字段当作 0 来跳过导致后续字段偏移错乱。解决构造报文时所有保留字段一律清零别偷懒。可以在协议结构体初始化时用memset先清一遍再填充有效字段。尤其注意 BTH 里 PSN 和 QPN 之间的保留位那是高频踩坑区。5.3 SL 和 VL 混用概念混淆导致 QoS 策略不生效现象配置了 SL3 到 VL3 的映射但业务流量实际走了 VL0 的通道拥塞时互相影响。原因SL 是报文头的字段VL 是物理通道编号两者之间靠仲裁表映射。映射关系由 SM 下发不是交换机固件写死的。如果 SM 没下发映射表或者端口没重载配置默认回落到 SLVL 的直通映射。解决用smconfig之类工具查看端口实际的 SL-to-VL 映射表确认配置已生效。还要注意映射表只在端口 LinkUp 后加载链路重启后要重新下发。若现场没有 SM 工具可以制造不同 SL 的流量用计数器观察各 VL 的字节数来验证。5.4 MTU 枚举与字节数换算错误现象配置 MTU 为 4096实际最大传输单元却是 2048大包直接丢。原因Vol 2 里的 MTU 枚举值标的是类似MTU_4096的名字但中间有一档是 2048有些驱动代码把枚举数组的下标当成字节数使用数字就翻倍了。解决枚举到字节数的换算用查表方法不要用位移计算。代码里做一个mtu_enum_to_bytes的常量数组并且加单元测试覆盖所有枚举值。这个测试成本低但能挡住大半年换一次硬件平台时最隐蔽的坑。5.5 链路层与传输层版本号混淆现象链接对端的设备上报的 TVer 和 LVer 都正常但握手后立刻断开日志里没有任何明显报错。原因有些厂商 SDK 用了同一个寄存器保存 LVer 和 TVer读出来的值可能都是 0看起来正常但实际写入时可能把两个版本号写反了。两边版本协商时对不上链路就重置。解决按 Vol 2 的表逐项核对寄存器 bit 位的分配确认 LVer 在 LRH 的位置TVer 在 BTH 的位置。如果设备支持ibv_devinfo可以直接看软件层报告的能力版本跟硬件寄存器交叉比对。如果两边都能读到那基本是寄存器配置问题不是物理层问题。6. 进阶用一套交叉验证法把规范读薄读完整份规范最好的验收方式不是把每页都背下来而是用自己手头的环境做交叉验证。我自己有一套固定流程每次拿到新版 Vol 2 都会走一遍。首先拿一台练手用的 IB 网卡用ibv_devinfo拉出端口状态、活跃速率、MTU 和 SL 映射表跟 Vol 2 里给的参数范围逐项对照。对照的重点集中在三个地方端口 MTU 枚举值是否在规范表格里存在、链路速率对应的物理层编码方式是否与其一致、SL 到 VL 的默认映射是否和规范给出的默认建议相同。做完这步你已经把抽象文档和真实硬件焊在一起了。接着抓一份简单的 RC 连接报文拿tcpdump或者ibdump抓下来手动解析 LRH 和 BTH校验解析结果和驱动日志里的 QPN、PSN 是否一致。如果一致说明你的位宽理解是对的。我还会额外做一件事把 Vol 2 里跟链路层错误检测相关的文字通读一遍然后用故意构造的坏包比如改错 VCRC去验证对端是否按规范重传。OpenSM 里可以临时改一些转发配置让报文故意走错路径顺便观察 SL 到 VL 的映射是否被真正执行。整套流程走完这份 2.0 最终版在你手里就已经不是一本黑匣子一样的 PDF而是一张可以随时展开的排错地图。这套验证方法尤其适合刚接手 IB 相关项目的工程师。规范太厚不可能一次全记住但交叉验证会把高频用到的几十个参数固化到你的实际操作里。从那以后我每次拿到新版规范都会强制自己走一遍“拉参数、抓报文、对版本”的流程不为别的只为了在真正出事的时候能第一时间判断是配置错了还是设备实现跟规范有出入。希望这套方法对你也同样有用。本文还有配套的精品资源点击获取