简介InfiniBand架构卷1的Release 1.7最终版官方规范面向高性能计算、数据中心与存储网络领域的架构师、工程师及研究人员。文档完整收录1.0至1.7的版本修订历史与更新说明在1.6基础上新增网络探测Network ProbeAnnex A20并更新内存放置扩展、大基数交换机管理及XDR速率相关定义。规范还涵盖虚拟化附件、RoCE-v1/v2标准、MPE扩展、传输层操作码扩展、子网管理及管理机制等核心技术可帮助读者准确掌握从早期InfiniBand到现代高速互联的完整技术框架。从1.0纠错、1.4引入虚拟化与RoCE到1.7新增网络探测与XDR支持版本演进清晰展现了带宽、延迟与扩展性的持续突破。压缩包内共1个PDF文件规格统一总大小约13.82MB便于离线阅读和长期保存。文档中链路层、传输层、物理层等定义齐全附录包含多项实用扩展适合作为日常研发的参考工具。当前已有483人下载学习是深入理解和研究InfiniBand协议体系的高价值参考资料。1. 拿到这份 IB 规范卷一先别急着翻页做 InfiniBand 的人手里大概率都留过一份IB Specification Vol 1-Release-1.7-Final-2023-07-11。这是 InfiniBand 架构规范卷一的 1.7 最终版发布日期 2023 年 7 月 11 日之后所有支持 InfiniBand 的网卡、交换机和子网管理器都要以这一版作为协议对齐的基准。它不教你怎么装驱动它回答的是更底层的问题IB 报文协议从头到尾每个字段占几位、UD 和 RC 的报文头差在哪、MTU、SL、VL、P_Key 这些参数到底按什么规则生效。适合刚接手 IB 集群却被 ibstat 输出难住的运维也适合写 RDMA 中间件却总被“对方 Q_Key 不对”困扰的开发。想把 IB 不当作玄学来排错这份规范就是唯一的坐标系。2. 把 Vol 1 当地图读IB 报文协议的四层结构与一段报文的旅程2.1 四层架构分别管什么链路层靠“包交换”而不是路由Vol 1 的目录结构基本就是 IB 报文协议的骨架它把通信要素拆成物理层、链路层、网络层、传输层四层。物理层管电气信号和链路速率SDR/FDR/EDR/HDR 的速率等级表在这里不过具体的眼图和连接器细节更多放在 Vol 2卷一只是在协议层面引用它。链路层是 IB 区别于以太网的关键分界。它不叫“路由”叫“包交换”每个端口根据 LRH 里的 DLID 决定把报文送到哪个本地端口。网络层在单子网内基本不干活只有跨子网和组播场景才会在报文里带 GRH。传输层再往上负责端到端投递语义定义 OpCode、PSN 和重传行为。我最早读这章时最容易被绕晕的问题是“链路层到底做不做重传”。IB 链路层的职责是流控用信用量credit机制保证物理链路上不丢帧但链路层不负责端到端重传。端到端重传是传输层 RC/RD 服务的事。这个边界在排障时特别重要链路层丢帧方向是查物理信号和 credit 流控传输层 PSN 重传计数高则多半要回到两个 QP 之间的 SL、VL 映射去查。注意Vol 1 里链路层只说“不丢帧”不保证“不丢包”。丢包后的重传行为要去传输层服务里找答案。2.2 报文头是怎么一层层叠上去的LRH、BTH 与扩展头一段真实的 IB 报文不是一坨扁平的字节而是像洋葱一样一层层包出来的。Vol 1 在描述报文格式时用的就是“本地路由头 传输头 Payload 校验”的框架。下表是我每次抓包都要对照的报文头清单头字段长度在报文里的作用LRH8 字节本地路由VL、SL、LNH、DLID、SLID、包长GRH40 字节全局路由跨子网或组播时可选携带BTH12 字节传输基础头OpCode、P_Key、目的 QP、PSNDETH / RETH / Atomic8 / 16 / 16 字节按传输服务类型附加的扩展头Payload按需用户数据或 SEND 数据ICRC4 字节不变校验覆盖 LRH 之后到 Payload 末尾VCRC4 字节链路间可变校验覆盖整包头一个值得抠的字段是 LRH 里的 LNH它只有 2 个 bit却决定“下一个头是什么”。如果 LNH 指向 BTH这就是单子网内的普通数据报文如果指向 GRH说明后面还跟着 40 字节的全局路由头需要 SM 做跨子网转发。很多人在子网边界上配了路由却忘记看 LNH导致报文被当作单子网帧丢弃。调这类问题先对着这份表把头的顺序对上比瞎猜链路状态有意义得多。2.3 包长字段的算法为什么抓包里看到的值总和你想象的不一样LRH 里有一个 11 bit 的包长字段它按 4 字节为单位表示长度。Vol 1 的定义是从 LRH 之后开始算到 ICRC 结束所有字节数除以 4。也就是说它不包括 LRH 自己的 8 字节也不包括链路尾巴上的 VCRC。于是很多人按“LRH BTH Payload VCRC”手动算帧长怎么算都比 LRH 字段表达的值多出 8 字节反过来如果只算“BTH Payload”又恰好差在 ICRC 和 GRH 上。判断报文合法性的时候正确的读法是LRH.PacketLength × 4 GRH若有 BTH 扩展头 Payload ICRC而物理链路上真正跑的字节数还要再加 LRH 和 VCRC。这两套数字之间的关系Vol 1 在链路层定义里写得很清楚但初读的人总把“包长”当成“帧长”。我后来养成的习惯是任何报文解析代码里先声明“长度口径”再谈字段偏移。口径没对齐后面所有基于长度的判断都会连续翻车。3. 传输服务怎么选UD、RC、UC 在规范里的定义与报头差异3.1 三种主流传输服务对比可靠性、连接性与头开销Vol 1 把传输服务分成 Reliable ConnectionRC、Unreliable ConnectionUC、Reliable DatagramRD、Unreliable DatagramUD四类外加 Raw 类型。实际在数据中心里能见到的主要是 RC 和 UDUC 偶见于特定硬件RD 大多停留在规范定义里。把这个表记在心里比背几十页伪代码有用传输服务是否建立连接是否可靠典型场景RC是QP 一一对应可靠硬件做重传和排序存储、MPI、大数据传输UC是QP 一一对应不可靠无重传少用部分加速场景UD否一对多/多对一不可靠无重传支持组播子网管理、IPoIB、控制面消息RD否但硬件跟踪可靠定义完整商用实现极少选型的判断逻辑我一般只看两条能不能接受乱序和丢失以及 QP 数量会不会成为瓶颈。存储和 MPI 必须选 RC因为底层数据不能丢控制面和广播类消息选 UD因为要发给多个接收方而且接收方不需要维护一堆 QP。IPoIB 的广播和组播就是建立在 UD 之上的。规范里 RC 和 UD 的报文头差异也很直观UD 必须带 8 字节的 DETH里面放 Q_Key 和源 QPRC 则不需要 DETH但做 RDMA Write/Read 时要带 16 字节的 RETH里面是虚拟地址、RKey 和长度。3.2 从 BTH 读起OpCode、P_Key 和 PSN 怎么协作BTH 是每个 IB 数据报文都有的 12 字节头部也是 Vol 1 里被引用最多的字段集合。它的前 8 bit 是 OpCode告诉你这个报文是 SEND First、SEND Middle、SEND Last还是 RDMA Write 的分片又或者是 ACK。OpCode 语义决定了接收方如何把多个分片重组以及要不要回复。实际排障时OpCode 是判断“对方到底收到没有”的第一依据一直在重发 SEND Last说明对端没有回 ACK问题多半不在物理链路而在 QP 状态。P_Key 也在 BTH 里占 16 bit它是 IB 分区机制的核心。每个端口维护一张 P_Key 表报文进入端口时交换机和接收端都会核对 P_Key不一致直接丢弃并计入错误计数器。PSN 是 24 bit 的发送序号配合 BTH 里的 A 位ACK 请求位实现可靠传输。RC 服务就是靠 PSN 连续性和重传位图判断要不要重传。读 BTH 时还有个容易忽略的点P_Key 不是“VLAN ID”它是一个准入开关两个端口 P_Key 值相同只是必要条件还要看成员类型是否允许互通这个坑在第 5 章单独展开。3.3 Q_Key 在 DETH 里UD 通不通先看这把“钥匙”UD 服务里有一个以太网世界找不到的概念叫 Q_Key全称 Queue Pair Key32 bit位于 DETH 的前 4 字节。Vol 1 把它定义为“UD 接收端对发送端进行合法性校验的键值”。接收端 QP 在初始化时设置自己的 Q_Key收到的每个 UD 报文都会拿 DETH 里的 Q_Key 跟自己的配置比对不一致就把报文扔掉同时累加 Q_Key violation 计数器。所以它更像一把“共享钥匙”而不是加密用的密码。这里要特别提醒Q_Key 不是 RKey。RKey 是 RDMA 操作中用来授权远端读写本地内存的属于 RC 服务的安全机制Q_Key 只保护 UD 数据报的接收。两者都带“Key”这个词但字段位置、授权客体和报文位置完全不同。把 Q_Key 当 RKey 配错典型表现是 UD 管理报文能发不能收对端还报 Q_Key violation。规范预留了几个著名的全局 Q_Key比如0x11111111用于子网管理 QP0 这类特殊通道普通应用不要去占。4. 调参数前先翻规范MTU、SL、VL 与 P_Key 的正确打开方式4.1 MTU 协商端口标称 4096 不代表报文能按 4096 跑IB 的 MTU 和以太网 MTU 有个本质区别IB 规范里的 MTU 指的是 Payload 的最大字节数不是整帧长度。Vol 1 允许的 Payload MTU 只有四档256、512、1024、2048、4096端口在链路初始化时会协商出一个两端共同支持的 active MTU。4096 只在两端及路径上所有交换机都支持时才成立。子网管理器计算路径 MTU 时取的是整条路径上的最小值任何一段物理链路降速路径 MTU 都可能跟着掉档。调 MTU 时最常犯的错误是把应用层设置的发送缓冲区大小直接跟 4096 比。RDMA SEND 的 Payload 可以小于等于路径 MTU超过则要应用自己分片或者改用 RC 的 RDMA Read/Write。查看当前生效值不要看驱动默认配置要看协商结果ibv_devinfo -d mlx5_0 | grep -E max_mtu|active_mtu输出里active_mtu: 4096 (5)这种格式括号内的数字是枚举值不是字节数。实际字节数要看前面的 4096。如果看到 active_mtu 比 max_mtu 低一大截先查是否有交换机端口降速或者线缆类型不匹配再去调 SM 的 MTU 策略顺序反了会浪费很多时间。4.2 SL、VL 和 QoS优先级不是“设一个数字”这么简单Vol 1 的 QoS 体系由 Service LevelSL和 Virtual LaneVL共同构成。SL 是 4 bit 的端到端服务等级标签取值范围 0 到 15携带在 LRH 里VL 是物理链路内部的虚拟通道最多 16 条用于隔离不同的流量。SL 和 VL 不是同一个东西SL 是逻辑标签VL 是物理缓冲队列。每个端口从子网管理器拿到一张 SL2VL 映射表硬件在发送时把报文里的 SL 映射成对应的 VL。实际调 QoS 时只在报文中把 SL 设成高优先级没有意义链路还得有 VL 仲裁表VL Arbitration Table来分配每个 VL 可以占用的带宽比例。Vol 1 定义了 VL 仲裁表的结构分高优先级和低优先级两张表子网管理器把表下发到每个端口。在 OpenSM 里对应的是sl2vl映射和vlarb表配置。一个常见做法是先用opensm -c /etc/opensm/opensm.conf生成默认配置修改SL2VL和VLArb两段重启 opensmd让 SM 重新下发映射表。调完不要只看业务带宽要同时看端口的 VL 丢弃计数。规范里 VL 仲裁是强制的配置出错时高优先级报文可能把低优先级报文全部饿死这种问题在带宽监控上很难看出来只能读硬件计数器。4.3 P_Key 分区表Key 相同也可能不通P_Key 分区是 IB 子网里做隔离的主要手段它在 BTH 中占据 16 bit但实际可用的分区号是低 15 bit最高位是成员类型位。Vol 1 把成员类型分成 Full Member 和 Limited Member0 表示 Full Member1 表示 Limited Member。两个 Full Member 可以互通Full 与 Limited 可以互通但两个 Limited Member 之间不能互通。20 个端口的子网里配了同一个 P_Key 却互相 ping 不通十有八九是两端都用了 Limited Member。另一种形态是 P_Key 表和索引的关系。每个端口的 P_Key Table 有多个表项表项的索引是 0 到 15 或更多但真正在 BTH 里传输的是 P_Key 值本身不是索引。所以两端使用的表项索引可以不同只要 P_Key 值一致且成员类型兼容就行。用ibpkeydb可以 dump 子网里 SM 视角的 P_Key 分区表实际查的时候重点看同一分区内是否混入了不同成员类型以及有没有端口的 default P_Key 被覆盖成了其他值。分区配置出问题表现往往是“abort 连接”而不是“报错失败”因为硬件直接把报文丢了软件层只能看到超时。5. 避坑读 IB 规范卷一时最容易踩的 4 个误区5.1 现象算报文长度总是差 4 或 8 字节按照 LRH 里的 PacketLength 字段去算报文长度结果和抓包工具显示的总长度对不上有时候差 4 字节有时候差 8 字节。第一次遇到时我以为是自己位偏移算错了反复对了三遍还是对不上。原因在于 Vol 1 对“长度”有两套口径。LRH.PacketLength 以 4 字节为单位且不计算 LRH 本身和 VCRC而抓包工具显示的往往是从 LRH 开头到 VCRC 末尾的完整字节数。当报文有 GRH 时差出来的 8 字节又恰好制造了“多一截”的错觉。解决方法是统一长度口径。解析报文时先算LRH.PacketLength×4得到逻辑长度再手动加上 LRH 的 8 字节和 VCRC 的 4 字节得到物理帧长。我在抓包解析脚本里固定用两个变量分别保存这两类值绝不复用一个变量。5.2 现象UD 传输报 Q_Key violation但两边明明“用同一个 Key”两个节点上的 UD 应用都配置了相同的 Q_Key 字符串运行时接收端却持续报 Q_Key violationibstat 里对应端口的 rx 错误计数不停上涨。原因通常不是 Key 字符串不一致而是 Q_Key 的生效位置不对。Vol 1 规定接收端 QP 在 Modify QP 时必须设置 qkey 属性发送端在发送时也要指定同一个 Q_Key。很多封装接口里发送端默认会用IBV_QPT_UD的默认值接收端却没有把 qkey 字段写进属性结构体导致接收端还是初始值。解决方法是把收发两端的 QP attribute 打开显式检查qp_attr.qkey和qp_attr_mask是否都设了 QKEY。用 libibverbs 时接收端要像下面这样处理不能只设置一次就以为永久生效ibv_devinfo -d mlx5_0 | grep -i active_mtu这条命令先确认端口基础状态正常再去代码里核对 Q_Key。经验是Q_Key 问题一半出在“发送端设了、接收端没设”和“API 默认值覆盖了用户值”这两种情况上。5.3 现象SL 配了高优先级业务流量还是被交换机丢给报文设了 SL15也确认端口支持多个 VL但高优先级业务在交换机上行口仍然出现丢包低优先级流量却正常。原因在于 SL 只是标签VL 才是真正排队的通道。SL 到 VL 的映射表没配对高优先级报文全被映射到了同一个低权重 VL或者 VL 仲裁表没有把该 VL 的权重调高。Vol 1 里 VL 仲裁表的权重单位是 64 字节块配置错误时看似“给了高优先级”实际调度权重还是默认值。解决方法是先确认 SL2VL 映射用ibv_devinfo看端口支持的 VL 数量再检查 SM 下发的映射表。OpenSM 里打开配置文件的SL2VL段把对应 SL 映射到独立 VL并在VLArb段提高该 VL 的高优先级仲裁权重然后重启 opensmd。改完看两个计数器端口级VL dropped和SL相关的拥塞丢弃。如果 VL dropped 还在涨说明映射是通的、调度权重不够如果不涨说明流量根本没走到这个 VL。5.4 现象P_Key 值相同分区却不互通两个端口 P_Key 值完全一样但上层应用无法通信链路状态又是 Active。原因几乎都是成员类型位的问题。很多人配置时直接用了0x0001、0x0002这种小数字但没注意 bit 15 设置为 0其实表示这是 Full Member。两端都配成 Limited Memberbit 15 置 1时Vol 1 规定它们之间不能互通。还有一种情况是配置工具自动在 P_Key 上加了0x8000一端是 Full 一端是 Limited看起来值不同实际却可以通最容易造成困惑。解决方法是统一用完整 P_Key 值做对比而不是只看低 15 位。查ibpkeydb的输出把两端的 P_Key 值按十六进制完整写出来先比低 15 位是否一致再比 bit 15 的成员类型是否满足互通规则。规则记一句就行Full 可以和 Full 通Full 可以和 Limited 通Limited 和 Limited 不通。6. 用 OpenSM 和 ibv_* 验证你从规范里读到的东西6.1 用 ibstat 和 ibv_devinfo 把端口参数对一遍规范读得再熟也要回到实际端口上验证。我每次接手一个新集群第一步永远是跑两条命令把端口状态、LID、MTU 和 SM 信息拉出来对齐# 查看所有 IB 端口概要状态、速率、LID ibstat # 查看指定设备端口的详细属性 ibv_devinfo -d mlx5_0 -i 1ibstat 里重点看State: Active、Physical state: LinkUp、Rate和Base lid。如果 State 不是 Active先看物理状态是不是 LinkUp再查 SM 是否在线。ibv_devinfo 里重点看port_lid、sm_lid、active_mtu。注意active_mtu显示为4096 (5)时括号里的 5 是枚举值而不是 MTU 字节数真正生效的 MTU 是前面的 4096。这套核对动作能把链路层和网络层的问题一次性过滤掉大半。6.2 跑通一条最小 UD 链路验证 MTU 上界端口参数核对完我会用 RDMA 自带的ibv_ud_pingpong做一次最小 UD 通路验证。它是 rdma-core 自带的测试工具直接操作 verbs 接口能在不写业务代码的情况下验证 UD 服务和 MTU 设置。# 服务端先启动-p 1 指定 IB 端口号-S 2048 指定 UD Payload 大小 ibv_ud_pingpong -d mlx5_0 -p 1 -S 2048 -n 1000 # 客户端再连末尾是对端地址和监听端口 ibv_ud_pingpong -d mlx5_0 -p 1 -S 2048 -n 1000 192.168.10.5 18515参数里-S 2048指的是 UD 报文的 Payload 大小它必须小于等于 active_mtu。如果设置超过当前 MTU工具会直接报参数错误这本身就是对 MTU 上界最直接的验证。-n 1000控制迭代次数日志会打印每一轮延迟和最终吞吐。需要补充的是ibv_ud_pingpong会自动把两端 Q_Key 配成同一个值所以它能验证的是链路和 UD 通路正常自定义 Q_Key 的校验逻辑仍要靠业务日志确认。跑通之后我还会用ibdump拉一小段端口镜像流量对照 LRH 和 BTH 的字段值确认实际报文里的 SL、P_Key、DLID 与配置一致。这个动作看起来慢但每次都能在“链路是通的业务却不通”的时候帮我省下半天瞎猜时间。我自己最常犯的错是拿以太网思路硬套 IBMTU 看总长、P_Key 当 VLAN、Q_Key 当密码。后来每改一个参数前都先翻一遍 Vol 1 对应的字段定义把“字段怎么读”写进排障清单踩坑率明显下降。希望你也能把这本规范用成自己的坐标系希望帮到你。本文还有配套的精品资源点击获取
