尧图网站建设 
简介《InfiniBand架构规范 第1卷 1.4版》是2020年由InfiniBand贸易协会发布的官方标准文档聚焦数据中心、高性能计算与RoCE网络场景面向需要理解IB基础架构与RDMA实现的网络工程师、协议研究者和开发者。文档包含完整规范正文在第一章概述技术设计目标、HCA/CA、交换机与串行连接等基本组件随后各章系统讲解传输协议、服务质量、错误处理、连接管理、QP/CQ、路由以及物理层与链路层规范并梳理了从1.0到1.4的版本演进便于对照历史修订。针对融合以太网规范特别收录RoCE-v1与RoCE-v2附录说明无损以太网要求、IPv4/IPv6支持与更灵活的网络配置。资源为单个PDF文件大小12.64MB适合离线查阅目前已有2854人学习是深入掌握InfiniBand技术体系和网络实践要点的权威参考资料。无论用于学习还是工程参考均能提供清晰权威的依据。1. 读懂 IB Specification Vol 1-Release-1.4.pdf这份文档到底管什么IB Specification Vol 1-Release-1.4.pdf 是 InfiniBand 工程师绕不开的一份正文IBTA 发布的这一卷把链路层、网络层、传输层和子网管理的行为全部写成了条款。对做 HPC、存储网络和 RDMA 加速的人来说它一半是字典、一半是边界字典告诉你 QP 状态机每一步怎么走边界告诉你为什么 4x 的线速永远不等于应用能拿到的带宽。我见过太多人把这份 PDF 丢进收藏夹吃灰出了问题就靠 ibstat 的输出猜。猜一两次还能蒙对遇到 MTU 不一致、P_Key 隔离、QP 状态卡死这类问题不回到规范原文你连错误现象都描述不准更别说定位。这份文档适合两类人已经会用 ibstat、ibv_devinfo但说不清队列对为什么需要四个状态的人以及刚接手 IB 集群想从协议层而不是交换机命令行建立全局观的运维。下面按我自己的读法和落地顺序讲照着走一遍比你从头翻一千页快得多。2. 规范的正确打开方式Vol 1 的架构地图与阅读顺序这份 PDF 最劝退的地方在厚度。实际上真正会反复查的不到三成问题是大部分人不知道这三成在哪几章。建议先画地图再决定精读哪块别从第一页顺序读下去那是给起草规范的人看的不是给调试集群的人看的。2.1 先把协议栈分工看清Vol 1 和 Vol 2 管的事不一样InfiniBand 协议栈从下往上分为物理层、链路层、网络层、传输层和管理层。Vol 1 管的是后四层加 Verbs 接口行为Vol 2 才管物理层也就是连接器、线缆、光模块、抖动和功耗这些东西。Release 1.4 在很多厂商的兼容性文档里被当作基线引述OFED 系列驱动和 rdma-core 的实现注释里经常能看到符合 Vol 1 Release 1.4这类描述这是它在存量环境里被引用最多的原因。这个分工直接决定排错方向。端口在 ACTIVE 和 LinkDown 之间抖动你去 Vol 1 找链路层条款是找不到答案的信号质量属于 Vol 2 和硬件手册的地盘。反过来QP 状态推不动、P_Key 校验失败这类问题去查硬件手册也没用必须回 Vol 1 的传输层和管理章节。先把这个边界划清楚能省下大量无效翻阅。2.2 建议精读的五块内容内容块定义了什么什么时候回来查架构概览与术语node、port、HCA、switch 的职责包packet在子网内的路由路径第一次读建立词汇表链路层报文格式、基于信用credit的流控、链路初始化状态链路时通时断、吞吐减半网络层与寻址LID/GID 结构、路由头、子网内转发规则配置静态路由、跨子网通信传输层QP 状态机、RC/UC/UD/RD 服务类型、可靠性语义写 verbs 程序、连接失败子网管理与 MADSM/SA 职责、P_Key 分区、路径记录PathRecord算 P_Key、查路径 MTU这五块里传输层和子网管理是排错时翻得最多的。链路层流控容易被忽略但吞吐问题一半以上跟它有关。网络层寻址相对简单LID 和 GID 的关系搞清楚就能应付大多数场景。2.3 阅读顺序第一遍和第二遍不一样第一遍建议按这个顺序架构概览 → 传输层 QP → 寻址 → 链路层流控 → 子网管理。QP 是 RDMA 的核心先把它状态机看明白后面理解寻址和流控就有了抓手。读的时候别逐字啃直接在 PDF 里搜三个词就够了Queue Pair、Subnet Management、Packet Format把这三块前后几页精读其余扫一眼标题。第二遍是排错时反着查的。从错误码出发回条款ibv_modify_qp 返回 EINVAL回传输层查状态机perftest 吞吐只有线速一半回链路层查 credit 和 VL 仲裁应用建链超时回子网管理查 P_Key 和路径记录。这个现象反向定位条款的习惯比把规范通读十遍都管用。提示选一个能把书签展开到三级的 PDF 阅读器把目录固定显示在侧栏。排错时这份规范就是字典书签就是索引检索效率决定你能不能在下班前解决问题。3. 队列对与寻址把 infiniband协议条款翻译成硬件行为很多工程师能倒背 ibstat 的输出但问到底层为什么是四个状态就说不清了。这一章把 infiniband协议里最核心的 QP 状态机和寻址机制讲透最后给两条命令把规范里的字段拉出来和实际环境核对。3.1 QP 状态机infiniband协议里连接是怎么活过来的规范里每个 QP 有六个状态Reset、Init、RTR、RTS、SQEr、Err。正常生命周期只有一条路径Reset → Init → RTR → RTS。每个跳变要携带的参数规范写得非常死少一个字段 HCA 就拒绝执行。Reset → Init 这一步配置的是本地身份P_Key、UD 服务要用的 Q_Key、访问权限本地写、远端读、远端写这些开关。Init → RTR 这一步配置的是远端信息对端 QPN、对端 LID、路径 MTU、接收队列深度。最后 RTR → RTS 才打开发送侧要配超时、重试计数和 RNR 重试参数。这个顺序不是随便定的。规范用状态机保证两端对连接视图的一致你还没告诉 HCA 对端在哪就让它发数据等于让快递员在没地址的情况下送件。自己写 verbs 程序的人最容易在这里翻车后面第五章会详细说。理解了这一点ibv_modify_qp 的四个调用就不再是背 API而是按规范走流程。3.2 LID、GID、P_Key路由和隔离是两件事寻址这块有三个标识符经常被混在一起说。LID 是 16 位子网内路由用由子网管理器SM分配相当于二层地址。GID 是 128 位由 64 位子网前缀加 64 位端口 GUID 组成概念上像 IPv6。P_Key 是 16 位分区键bit15 是成员位0 是受限成员1 是完全成员收发两端 P_Key 不匹配报文在接收端直接被丢。关键是理解 LID 和 P_Key 的分工LID 管怎么走到P_Key 管能不能进。两个端口在同一个子网、LID 互相可达并不代表应用能通信还得过 P_Key 校验这一关。很多业务连不上、但 ibping 全通的案例最后都栽在这。另外规范里 UD 服务还要过 Q_Key 校验RC 不用这也是排查时容易忽略的细节。3.3 用两条命令把规范参数拉出来核对读规范是为了验证现实。拿到一台机器我一般先跑这条ibstat | egrep State|Physical State|Rate|MTU说明一下怎么看输出。State 行显示 4: ACTIVE这是端口的逻辑管理状态Physical State 行显示 5: LinkUp这是链路物理状态。两者同时满足才算通。Rate 行和 MTU 行分别对应规范里的链路速率和 MTU 字段后面做性能对照时全靠这两行。再跑一条看驱动从 PortInfo 属性里落下来的细节ibv_devinfo -d mlx5_0 | egrep port_state|active_mtu|active_speed|active_width|lid这里的 active_speed、active_width、active_mtu 就是 Vol 1 的 PortInfo 属性在驱动层的样子。active_width4X、active_speed25.0 Gbps (EDR) 时线速才算 100G。如果 active_width 变成 1X速率直接除以 4这是应用跑不满带宽最常见的第一个坑比调任何应用参数都值得先查。4. 从规范参数到集群配置速率、MTU 与端口验收这一章把规范里的数值参数翻译成集群配置动作。看完能直接回答两个问题我的链路到底标称多少、实际多少新交付的端口怎么验收才算合格。4.1 链路速率与有效带宽对照表规范里每代速率的信令速率和有效数据率不是一回事中间被编码开销吃掉一部分。常说的 100G 是线速应用能拿到的是有效数据率。代际单通道信令速率编码方式4x 线速4x 有效数据率SDR2.5 Gb/s8B/10B10 Gb/s8 Gb/sDDR5 Gb/s8B/10B20 Gb/s16 Gb/sQDR10 Gb/s8B/10B40 Gb/s32 Gb/sFDR14.0625 Gb/s64B/66B56.25 Gb/s约 54.5 Gb/sEDR25.78125 Gb/s64B/66B103.125 Gb/s约 100 Gb/s8B/10B 编码的有效率是 80%64B/66B 是约 97%。这套关系在 1.x 版本的规范正文里都有完整定义你机器上跑的是哪一代拿 ibstat 的 Rate 行对照这张表即可。MTU 是另一个关键数值。可选值有 256、512、1024、2048、4096 五档。大包吞吐场景优先 4096但前提是路径上所有交换机端口都支持否则子网管理器会把路径 MTU 协商到最小值。延迟敏感的小消息场景不必强求 4096报文头开销在小包下占比更高MTU 对延迟的影响没有对吞吐那么直接。4.2 一张可以直接照抄的端口验收清单新端口上线我按下面六步验收每一步都能对应到规范条款查端口状态和物理状态确认 ACTIVE LinkUp。查 active_width 和 active_speed确认不是 1X 降速。查链路错误计数器确认没有反复降级恢复。用 ibping 打一次连通性分 LID 和 GUID 两种方式。用 ib_write_bw 拉一次带宽和 4.1 的表对照。查 P_Key 表确认业务分区和默认分区都在。其中第三步的计数器在 sysfs 里可以直接读iblinkinfo | head -30 cat /sys/class/infiniband/mlx5_0/ports/1/counters/link_error_recovers cat /sys/class/infiniband/mlx5_0/ports/1/counters/symbol_errorlink_error_recovers 持续增长说明链路在反复降级又恢复这种抖动最磨人symbol_error 增长说明信号质量差多半是光模块、线缆或者连接器的问题。这两个计数器就是规范里链路错误恢复机制的落地表现比任何应用层日志都早暴露问题。4.3 QP 深度、CQ 大小和 inline 的常用取值应用侧参数规范不强制但给出的是可用的基线。QP 的 send/recv queue depth吞吐型任务我一般设 1024 到 4096深度大能扛住瞬时 ops 峰值但占内存和 cache延迟敏感型任务设 128 到 512 就够太深反而让 cache 命中率下降。CQ 大小按所有关联 QP 深度之和来设或者按最坏情况在途 ops 数乘以 2避免应用跑到一半 CQ 溢出丢完成事件。inline 阈值我一般这样设小于等于 64 字节的 SEND 走 inline把数据直接塞进 WQE省一次 DMA 读。连接数多、消息又稀疏的场景用 SRQ 替代每 QP 独立接收队列内存能省一大截但要留意 SRQ 下的 RNR 重试行为和独立 RQ 不完全一样规范里对 SRQ 的接收 WR 归属写得很清楚用之前建议翻一下。5. 避坑排查读规范时最容易翻车的五个常见问题下面五条都是我在集群上实际遇到、最后回规范条款才对上号的问题。每条按现象、原因、解决写可以直接当排查手册用。前三条是配置和代码问题后两条是理解问题理解问题往往更致命。5.1 MTU 不一致ibping 全通大消息卡死现象ibping 正常小消息也正常但 RDMA write 大 buffer 要么超时要么卡住应用日志里看不到明确报错。原因路径上两端或交换机端口的 MTU 不一致规范要求路径记录按最小 MTU 协商但混合厂商环境下 SM 生成的通知不一定在所有设备上生效实际传输还是按各自的 MTU 走。解决用 ibstat 看两端 MTU在子网管理器配置里把最大 MTU 统一到同一档位重新下发配置后让 SM 重算路径记录再验证一次两端 active_mtu。5.2 P_Key 对不上端口全绿业务连不上现象ibstat 看两个端口都 ACTIVE链路状态完美但业务应用建链超时dmesg 或者应用日志里有 pkey 相关提示。原因两端端口的分区键不匹配或者成员位不一致。默认的 0xFFFF 分区能过 ibping但业务 QP 用的是具体分区键比如 0x8001这个键在两端分区表里对不上报文在接收端直接被丢。解决对比两端/sys/class/infiniband/*/ports/*/pkeys/目录下的值确认 0x8001 这类业务键和成员位完全一致再回到 SM 的 partition 配置里对齐别只靠 ibping 判断分区没问题。5.3 QP 停在 RTR自己写 verbs 最常见的错现象用 rdma res show qp 看到 QP state 停在 RTR或者对端一直报 RNR timeout程序起不来。原因modify_qp 的调用顺序没按 Reset → Init → RTR → RTS 走。常见两种情况还没把远端信息填进 RTR就把发送侧推到 RTS或者在 RTR 之前没投递 receive WR接收队列是空的对端一发数据就 RNR。解决严格按状态机分四步调 modify_qp每步只填该状态需要的属性在 RTR 之前把该投的 receive WR 投完再执行 RTR → RTS。改完再用 rdma res show qp 确认状态推进到 RTS这一步能省大量抓包时间。5.4 只看 Vol 1 不看物理层链路抖动像玄学现象端口在 ACTIVE 和 Down 之间反复横跳链路错误计数持续增长SM 配置怎么调都没用。原因把规范卷的分工搞混了。Vol 1 管协议行为但光模块功率不足、线缆老化、连接器接触不良这些信号质量问题属于 Vol 2 和硬件手册的管辖范围你在子网管理器配置里空转当然无效。解决先看 symbol_error 和 link_error_recovers 这两个计数器的增长趋势确认是信号问题后直接换线换模块别在协议层面浪费时间。链路抖动不是玄学只是找错了规范的卷。5.5 把 credit 流控当成 TCP 窗口现象吞吐骤降但 ping 正常、错误计数也正常调大重试参数完全没用。原因InfiniBand 链路层用的是信用令牌流控接收端 buffer credit 耗尽时发送端是暂停发送不是丢包重传。把它当 TCP 窗口去理解就会去调超时和重试方向完全错了。解决检查流量是不是集中压在一个 VL 上调整 SL2VL 映射和 VL 仲裁权重让流量分布到多个 VL同时确认接收端 HCA 的 buffer class 配置够用。credit 流控是设计上保证无损网络的关键理解它之后很多吞吐问题会重新归类到 QoS 而不是重传。6. 用规范反推性能瓶颈一张速查表和两条验证路径最后一章给两个能直接落地的工具一张瓶颈现象到规范字段的映射表和两条验证命令。遇到性能问题先过一遍能少走一半弯路。6.1 瓶颈现象 → 规范字段速查表现象先查什么带宽只有线速一半active_width 是否 1Xlink_error_recovers 是否增长延迟比预期高很多跳数、SL2VL 映射、是否配置了 QoS 策略小消息吞吐差路径 MTU 是否被协商到 256/512CPU 占用异常高CQ 事件模式、inline 是否真正生效流量抖动无规律symbol_error、VL 流量分布这张表就是从规范字段反着映射回现象。性能问题大多不是应用代码问题而是某个规范字段没落在预期位置。6.2 两条最常用的验证命令ib_read_lat -a -d mlx5_0 -s 16 -n 1000 ib_write_bw -a -d mlx5_0 -q 4 -s 1048576-a 是自动选端口-d 指定设备-s 是消息大小-n 是迭代次数-q 是 QP 深度。第一条测小消息读延迟第二条测大消息写带宽。在 EDR 直连的两台机器上写带宽应该接近 90Gb/s 甚至更高读延迟在个位数微秒量级。差得远就把 6.1 的表从头过一遍先看速率和宽度再看错误计数器这两步能定位大部分问题。6.3 我自己的习惯我的习惯是每次接手新集群先按第三章的命令把每台机器的 active_speed、active_width 和错误计数器记一张表再和第四章的速率对照表比对。血泪经验是太多性能问题最后都归结到 1X 降速、MTU 协商、P_Key 这三件事上每次都从规范字段对照起别急着调应用参数。把这份思路带进你的日常排错流程IB Specification Vol 1-Release-1.4.pdf 就会从收藏夹里的古董变成最顺手的工具。希望帮到你。本文还有配套的精品资源点击获取 InfiniBand协议规范解读：从QP状态机到P_Key排错实战
简介《InfiniBand架构规范 第1卷 1.4版》是2020年由InfiniBand贸易协会发布的官方标准文档聚焦数据中心、高性能计算与RoCE网络场景面向需要理解IB基础架构与RDMA实现的网络工程师、协议研究者和开发者。文档包含完整规范正文在第一章概述技术设计目标、HCA/CA、交换机与串行连接等基本组件随后各章系统讲解传输协议、服务质量、错误处理、连接管理、QP/CQ、路由以及物理层与链路层规范并梳理了从1.0到1.4的版本演进便于对照历史修订。针对融合以太网规范特别收录RoCE-v1与RoCE-v2附录说明无损以太网要求、IPv4/IPv6支持与更灵活的网络配置。资源为单个PDF文件大小12.64MB适合离线查阅目前已有2854人学习是深入掌握InfiniBand技术体系和网络实践要点的权威参考资料。无论用于学习还是工程参考均能提供清晰权威的依据。1. 读懂 IB Specification Vol 1-Release-1.4.pdf这份文档到底管什么IB Specification Vol 1-Release-1.4.pdf 是 InfiniBand 工程师绕不开的一份正文IBTA 发布的这一卷把链路层、网络层、传输层和子网管理的行为全部写成了条款。对做 HPC、存储网络和 RDMA 加速的人来说它一半是字典、一半是边界字典告诉你 QP 状态机每一步怎么走边界告诉你为什么 4x 的线速永远不等于应用能拿到的带宽。我见过太多人把这份 PDF 丢进收藏夹吃灰出了问题就靠 ibstat 的输出猜。猜一两次还能蒙对遇到 MTU 不一致、P_Key 隔离、QP 状态卡死这类问题不回到规范原文你连错误现象都描述不准更别说定位。这份文档适合两类人已经会用 ibstat、ibv_devinfo但说不清队列对为什么需要四个状态的人以及刚接手 IB 集群想从协议层而不是交换机命令行建立全局观的运维。下面按我自己的读法和落地顺序讲照着走一遍比你从头翻一千页快得多。2. 规范的正确打开方式Vol 1 的架构地图与阅读顺序这份 PDF 最劝退的地方在厚度。实际上真正会反复查的不到三成问题是大部分人不知道这三成在哪几章。建议先画地图再决定精读哪块别从第一页顺序读下去那是给起草规范的人看的不是给调试集群的人看的。2.1 先把协议栈分工看清Vol 1 和 Vol 2 管的事不一样InfiniBand 协议栈从下往上分为物理层、链路层、网络层、传输层和管理层。Vol 1 管的是后四层加 Verbs 接口行为Vol 2 才管物理层也就是连接器、线缆、光模块、抖动和功耗这些东西。Release 1.4 在很多厂商的兼容性文档里被当作基线引述OFED 系列驱动和 rdma-core 的实现注释里经常能看到符合 Vol 1 Release 1.4这类描述这是它在存量环境里被引用最多的原因。这个分工直接决定排错方向。端口在 ACTIVE 和 LinkDown 之间抖动你去 Vol 1 找链路层条款是找不到答案的信号质量属于 Vol 2 和硬件手册的地盘。反过来QP 状态推不动、P_Key 校验失败这类问题去查硬件手册也没用必须回 Vol 1 的传输层和管理章节。先把这个边界划清楚能省下大量无效翻阅。2.2 建议精读的五块内容内容块定义了什么什么时候回来查架构概览与术语node、port、HCA、switch 的职责包packet在子网内的路由路径第一次读建立词汇表链路层报文格式、基于信用credit的流控、链路初始化状态链路时通时断、吞吐减半网络层与寻址LID/GID 结构、路由头、子网内转发规则配置静态路由、跨子网通信传输层QP 状态机、RC/UC/UD/RD 服务类型、可靠性语义写 verbs 程序、连接失败子网管理与 MADSM/SA 职责、P_Key 分区、路径记录PathRecord算 P_Key、查路径 MTU这五块里传输层和子网管理是排错时翻得最多的。链路层流控容易被忽略但吞吐问题一半以上跟它有关。网络层寻址相对简单LID 和 GID 的关系搞清楚就能应付大多数场景。2.3 阅读顺序第一遍和第二遍不一样第一遍建议按这个顺序架构概览 → 传输层 QP → 寻址 → 链路层流控 → 子网管理。QP 是 RDMA 的核心先把它状态机看明白后面理解寻址和流控就有了抓手。读的时候别逐字啃直接在 PDF 里搜三个词就够了Queue Pair、Subnet Management、Packet Format把这三块前后几页精读其余扫一眼标题。第二遍是排错时反着查的。从错误码出发回条款ibv_modify_qp 返回 EINVAL回传输层查状态机perftest 吞吐只有线速一半回链路层查 credit 和 VL 仲裁应用建链超时回子网管理查 P_Key 和路径记录。这个现象反向定位条款的习惯比把规范通读十遍都管用。提示选一个能把书签展开到三级的 PDF 阅读器把目录固定显示在侧栏。排错时这份规范就是字典书签就是索引检索效率决定你能不能在下班前解决问题。3. 队列对与寻址把 infiniband协议条款翻译成硬件行为很多工程师能倒背 ibstat 的输出但问到底层为什么是四个状态就说不清了。这一章把 infiniband协议里最核心的 QP 状态机和寻址机制讲透最后给两条命令把规范里的字段拉出来和实际环境核对。3.1 QP 状态机infiniband协议里连接是怎么活过来的规范里每个 QP 有六个状态Reset、Init、RTR、RTS、SQEr、Err。正常生命周期只有一条路径Reset → Init → RTR → RTS。每个跳变要携带的参数规范写得非常死少一个字段 HCA 就拒绝执行。Reset → Init 这一步配置的是本地身份P_Key、UD 服务要用的 Q_Key、访问权限本地写、远端读、远端写这些开关。Init → RTR 这一步配置的是远端信息对端 QPN、对端 LID、路径 MTU、接收队列深度。最后 RTR → RTS 才打开发送侧要配超时、重试计数和 RNR 重试参数。这个顺序不是随便定的。规范用状态机保证两端对连接视图的一致你还没告诉 HCA 对端在哪就让它发数据等于让快递员在没地址的情况下送件。自己写 verbs 程序的人最容易在这里翻车后面第五章会详细说。理解了这一点ibv_modify_qp 的四个调用就不再是背 API而是按规范走流程。3.2 LID、GID、P_Key路由和隔离是两件事寻址这块有三个标识符经常被混在一起说。LID 是 16 位子网内路由用由子网管理器SM分配相当于二层地址。GID 是 128 位由 64 位子网前缀加 64 位端口 GUID 组成概念上像 IPv6。P_Key 是 16 位分区键bit15 是成员位0 是受限成员1 是完全成员收发两端 P_Key 不匹配报文在接收端直接被丢。关键是理解 LID 和 P_Key 的分工LID 管怎么走到P_Key 管能不能进。两个端口在同一个子网、LID 互相可达并不代表应用能通信还得过 P_Key 校验这一关。很多业务连不上、但 ibping 全通的案例最后都栽在这。另外规范里 UD 服务还要过 Q_Key 校验RC 不用这也是排查时容易忽略的细节。3.3 用两条命令把规范参数拉出来核对读规范是为了验证现实。拿到一台机器我一般先跑这条ibstat | egrep State|Physical State|Rate|MTU说明一下怎么看输出。State 行显示 4: ACTIVE这是端口的逻辑管理状态Physical State 行显示 5: LinkUp这是链路物理状态。两者同时满足才算通。Rate 行和 MTU 行分别对应规范里的链路速率和 MTU 字段后面做性能对照时全靠这两行。再跑一条看驱动从 PortInfo 属性里落下来的细节ibv_devinfo -d mlx5_0 | egrep port_state|active_mtu|active_speed|active_width|lid这里的 active_speed、active_width、active_mtu 就是 Vol 1 的 PortInfo 属性在驱动层的样子。active_width4X、active_speed25.0 Gbps (EDR) 时线速才算 100G。如果 active_width 变成 1X速率直接除以 4这是应用跑不满带宽最常见的第一个坑比调任何应用参数都值得先查。4. 从规范参数到集群配置速率、MTU 与端口验收这一章把规范里的数值参数翻译成集群配置动作。看完能直接回答两个问题我的链路到底标称多少、实际多少新交付的端口怎么验收才算合格。4.1 链路速率与有效带宽对照表规范里每代速率的信令速率和有效数据率不是一回事中间被编码开销吃掉一部分。常说的 100G 是线速应用能拿到的是有效数据率。代际单通道信令速率编码方式4x 线速4x 有效数据率SDR2.5 Gb/s8B/10B10 Gb/s8 Gb/sDDR5 Gb/s8B/10B20 Gb/s16 Gb/sQDR10 Gb/s8B/10B40 Gb/s32 Gb/sFDR14.0625 Gb/s64B/66B56.25 Gb/s约 54.5 Gb/sEDR25.78125 Gb/s64B/66B103.125 Gb/s约 100 Gb/s8B/10B 编码的有效率是 80%64B/66B 是约 97%。这套关系在 1.x 版本的规范正文里都有完整定义你机器上跑的是哪一代拿 ibstat 的 Rate 行对照这张表即可。MTU 是另一个关键数值。可选值有 256、512、1024、2048、4096 五档。大包吞吐场景优先 4096但前提是路径上所有交换机端口都支持否则子网管理器会把路径 MTU 协商到最小值。延迟敏感的小消息场景不必强求 4096报文头开销在小包下占比更高MTU 对延迟的影响没有对吞吐那么直接。4.2 一张可以直接照抄的端口验收清单新端口上线我按下面六步验收每一步都能对应到规范条款查端口状态和物理状态确认 ACTIVE LinkUp。查 active_width 和 active_speed确认不是 1X 降速。查链路错误计数器确认没有反复降级恢复。用 ibping 打一次连通性分 LID 和 GUID 两种方式。用 ib_write_bw 拉一次带宽和 4.1 的表对照。查 P_Key 表确认业务分区和默认分区都在。其中第三步的计数器在 sysfs 里可以直接读iblinkinfo | head -30 cat /sys/class/infiniband/mlx5_0/ports/1/counters/link_error_recovers cat /sys/class/infiniband/mlx5_0/ports/1/counters/symbol_errorlink_error_recovers 持续增长说明链路在反复降级又恢复这种抖动最磨人symbol_error 增长说明信号质量差多半是光模块、线缆或者连接器的问题。这两个计数器就是规范里链路错误恢复机制的落地表现比任何应用层日志都早暴露问题。4.3 QP 深度、CQ 大小和 inline 的常用取值应用侧参数规范不强制但给出的是可用的基线。QP 的 send/recv queue depth吞吐型任务我一般设 1024 到 4096深度大能扛住瞬时 ops 峰值但占内存和 cache延迟敏感型任务设 128 到 512 就够太深反而让 cache 命中率下降。CQ 大小按所有关联 QP 深度之和来设或者按最坏情况在途 ops 数乘以 2避免应用跑到一半 CQ 溢出丢完成事件。inline 阈值我一般这样设小于等于 64 字节的 SEND 走 inline把数据直接塞进 WQE省一次 DMA 读。连接数多、消息又稀疏的场景用 SRQ 替代每 QP 独立接收队列内存能省一大截但要留意 SRQ 下的 RNR 重试行为和独立 RQ 不完全一样规范里对 SRQ 的接收 WR 归属写得很清楚用之前建议翻一下。5. 避坑排查读规范时最容易翻车的五个常见问题下面五条都是我在集群上实际遇到、最后回规范条款才对上号的问题。每条按现象、原因、解决写可以直接当排查手册用。前三条是配置和代码问题后两条是理解问题理解问题往往更致命。5.1 MTU 不一致ibping 全通大消息卡死现象ibping 正常小消息也正常但 RDMA write 大 buffer 要么超时要么卡住应用日志里看不到明确报错。原因路径上两端或交换机端口的 MTU 不一致规范要求路径记录按最小 MTU 协商但混合厂商环境下 SM 生成的通知不一定在所有设备上生效实际传输还是按各自的 MTU 走。解决用 ibstat 看两端 MTU在子网管理器配置里把最大 MTU 统一到同一档位重新下发配置后让 SM 重算路径记录再验证一次两端 active_mtu。5.2 P_Key 对不上端口全绿业务连不上现象ibstat 看两个端口都 ACTIVE链路状态完美但业务应用建链超时dmesg 或者应用日志里有 pkey 相关提示。原因两端端口的分区键不匹配或者成员位不一致。默认的 0xFFFF 分区能过 ibping但业务 QP 用的是具体分区键比如 0x8001这个键在两端分区表里对不上报文在接收端直接被丢。解决对比两端/sys/class/infiniband/*/ports/*/pkeys/目录下的值确认 0x8001 这类业务键和成员位完全一致再回到 SM 的 partition 配置里对齐别只靠 ibping 判断分区没问题。5.3 QP 停在 RTR自己写 verbs 最常见的错现象用 rdma res show qp 看到 QP state 停在 RTR或者对端一直报 RNR timeout程序起不来。原因modify_qp 的调用顺序没按 Reset → Init → RTR → RTS 走。常见两种情况还没把远端信息填进 RTR就把发送侧推到 RTS或者在 RTR 之前没投递 receive WR接收队列是空的对端一发数据就 RNR。解决严格按状态机分四步调 modify_qp每步只填该状态需要的属性在 RTR 之前把该投的 receive WR 投完再执行 RTR → RTS。改完再用 rdma res show qp 确认状态推进到 RTS这一步能省大量抓包时间。5.4 只看 Vol 1 不看物理层链路抖动像玄学现象端口在 ACTIVE 和 Down 之间反复横跳链路错误计数持续增长SM 配置怎么调都没用。原因把规范卷的分工搞混了。Vol 1 管协议行为但光模块功率不足、线缆老化、连接器接触不良这些信号质量问题属于 Vol 2 和硬件手册的管辖范围你在子网管理器配置里空转当然无效。解决先看 symbol_error 和 link_error_recovers 这两个计数器的增长趋势确认是信号问题后直接换线换模块别在协议层面浪费时间。链路抖动不是玄学只是找错了规范的卷。5.5 把 credit 流控当成 TCP 窗口现象吞吐骤降但 ping 正常、错误计数也正常调大重试参数完全没用。原因InfiniBand 链路层用的是信用令牌流控接收端 buffer credit 耗尽时发送端是暂停发送不是丢包重传。把它当 TCP 窗口去理解就会去调超时和重试方向完全错了。解决检查流量是不是集中压在一个 VL 上调整 SL2VL 映射和 VL 仲裁权重让流量分布到多个 VL同时确认接收端 HCA 的 buffer class 配置够用。credit 流控是设计上保证无损网络的关键理解它之后很多吞吐问题会重新归类到 QoS 而不是重传。6. 用规范反推性能瓶颈一张速查表和两条验证路径最后一章给两个能直接落地的工具一张瓶颈现象到规范字段的映射表和两条验证命令。遇到性能问题先过一遍能少走一半弯路。6.1 瓶颈现象 → 规范字段速查表现象先查什么带宽只有线速一半active_width 是否 1Xlink_error_recovers 是否增长延迟比预期高很多跳数、SL2VL 映射、是否配置了 QoS 策略小消息吞吐差路径 MTU 是否被协商到 256/512CPU 占用异常高CQ 事件模式、inline 是否真正生效流量抖动无规律symbol_error、VL 流量分布这张表就是从规范字段反着映射回现象。性能问题大多不是应用代码问题而是某个规范字段没落在预期位置。6.2 两条最常用的验证命令ib_read_lat -a -d mlx5_0 -s 16 -n 1000 ib_write_bw -a -d mlx5_0 -q 4 -s 1048576-a 是自动选端口-d 指定设备-s 是消息大小-n 是迭代次数-q 是 QP 深度。第一条测小消息读延迟第二条测大消息写带宽。在 EDR 直连的两台机器上写带宽应该接近 90Gb/s 甚至更高读延迟在个位数微秒量级。差得远就把 6.1 的表从头过一遍先看速率和宽度再看错误计数器这两步能定位大部分问题。6.3 我自己的习惯我的习惯是每次接手新集群先按第三章的命令把每台机器的 active_speed、active_width 和错误计数器记一张表再和第四章的速率对照表比对。血泪经验是太多性能问题最后都归结到 1X 降速、MTU 协商、P_Key 这三件事上每次都从规范字段对照起别急着调应用参数。把这份思路带进你的日常排错流程IB Specification Vol 1-Release-1.4.pdf 就会从收藏夹里的古董变成最顺手的工具。希望帮到你。本文还有配套的精品资源点击获取