InfiniBand 专题【左扬精讲】—— InfiniBand 架构简介：从五层模型到子网管理

InfiniBand 专题【左扬精讲】—— InfiniBand 架构简介：从五层模型到子网管理

InfiniBand（通常简称 IB）在高性能计算（HPC）、AI 训练集群、分布式存储等场景里被广泛使用，它和我们熟知的以太网在协议设计思路、转发模型、管理方式上都有非常明显的差异。

本篇以 NVIDA 官方视频课程《第 2 单元 - InfiniBand 架构简介》为主线，从五层架构、数据包结构、Fabric vs. Subnet 区别、子网管理器、三层地址体系、OFED 工具集六个角度，把 InfiniBand 架构的 "骨架" 梳理清楚，为后续深入学习物理层、子网初始化、QoS 等主题打好基础。

本篇属于 "InfiniBand 专题【左扬精讲】" 系列的第一篇，定位是 架构入门，不涉及具体源码实现层面的调试，所有命令、术语、字段均来自课程原文及 OFED 官方工具惯例用法。

全文 6000 字左右，建议配合视频学习，并在自己环境里跑一遍 ibstat / ibping 工具加深印象。

本篇核心术语：InfiniBand 架构 / 子网管理器 SM / Fabric / Subnet / GUID / LID / GID / MAD / OFED
本篇核心命令：ofed_info / /etc/init.d/openibd status / lspci | grep -i Mellanox / ibstat / ibping / ibtracert

InfiniBandIB 架构子网管理 SMFabricSubnetGUIDLIDGIDOFEDibstatibpingibtracert

★ 学完这一篇你能掌握什么

本篇是 InfiniBand 架构的入门奠基篇，目标是建立完整的概念框架。以下是每个主题你需要掌握的深度说明：

  • 五层架构（What & How & Why）：
      • What：物理层 / 链路层 / 网络层 / 传输层 / 上层协议五层的各自职责
      • How：能说出每层对应的硬件设备（HCA/交换机/路由器）、协议头部（LRH/GRH/BTH）、数据包封装顺序
      • Why：理解"为什么 InfiniBand 采用分层设计"——与以太网 OSI 模型对比，管理层是显式存在而非隐式淹没在 SNMP 里
  • 数据包结构（What & How & Why）：
      • What：LRH（链路层路由头）/ GRH（全局路由头）/ BTH（传输层头）/ ETH（扩展传输头）四个头部的功能
      • How：能判断"什么场景下哪个头会出现"——同子网通信只需 LRH+BTH，跨子网需要 LRH+GRH+BTH；掌握每个头部的关键字段（SL/DLID/VL 在 LRH，SGID/DGID 在 GRH，PSN/Opcode 在 BTH）
      • Why：理解"数据包头部是如何一步步被添加/剥离的"——这是后续排查丢包、路径追踪问题的前置知识
  • Fabric vs. Subnet（What & How & Why）：
      • What：Fabric = 物理交换机+线缆组成的网络基础设施；Subnet = Fabric + 子网管理器 SM 的管理边界
      • How：能区分"一个物理 Fabric 可以划分多个 Subnet"、"每个 Subnet 必须有且仅有一个活跃 SM"、"Subnet 之间通过路由器隔离"
      • Why：这是 InfiniBand 和以太网最核心的设计差异——IB 是"管理先行"，网络能跑起来的前提是 SM 完成初始化
  • 子网管理器 SM（What & How & Why）：
      • What：SM 是 Subnet 内负责初始化、配置、监控网络的管理进程
      • How：掌握 SM 的四大职责（LID 分配/路径编程/路由转发/链路健康监控）、主备选举机制（Priority + GUID 的 LMC 算法）、部署位置（独立服务器 vs. 交换机嵌入式）
      • Why：理解"没有 SM，IB 网络寸步难行"——交换机配置丢失、主机加入/离开都需要 SM 重新计算拓扑
  • 三层地址体系（What & How & Why）：
      • What：GUID（全局唯一标识，厂商写入）/ LID（本地标识，SM 分配，16bit）/ GID（全局标识，64bit MAC + 64bit EUI-64 拼接）
      • How：能说出"设备上电后如何一步步获得 LID 和 GID"、"通信时源/目的地址用哪个"、"IPv6 地址和 GID 的关系"
      • Why：理解"为什么需要三层地址"——GUID 固定但不可路由，LID 高效但仅限子网内，GID 兼容 IPv6 实现跨子网
  • OFED 工具集（What & How & Why）：
      • What：OFED（OFED 是 Mellanox/NVIDIA 提供的一套驱动和工具）
      • How：能熟练使用 ibstat（查看 HCA 状态和端口信息）/ ibping（测试子网内连通性）/ ibtracert（追踪数据包路径），能读懂命令输出的 LID/GID/State 字段
      • Why：工具是理论的落地——理解 SM 分配 LID 的过程后，用 ibstat 验证"是否成功分配到 LID"是最直观的验证方式

★ 阅读前提 & 建议

  • 前置知识：建议了解以太网 OSI 七层模型（至少知道物理层/链路层/网络层的概念），本篇会频繁与之对比
  • 不涉及的内容：物理层电气特性（SerDes 速率/光模块型号）、QoS 信用计数器机制、子网初始化 FSM 状态机、RDMA verbs 源码分析
  • 深度预期：学完本篇后，你能看懂 ibstat / ibping / ibtracert 的输出，能回答"InfiniBand 为什么比以太网延迟低"——答案是"端到端无交换机 arbitration 争用 + 传输层硬件卸载"
  • 后续延伸：物理层信号完整性 → 子网初始化流程 → QoS 机制 → RDMA 操作语义 → 拥塞控制算法

📑 本节目录

  1. InfiniBand 架构分层与"管理"概念
  2. InfiniBand 数据包结构：LRH / GRH / BTH / ETH 四层头部
  3. Fabric vs. Subnet：物理基础设施 vs. 管理实体
  4. 子网管理器 SM：主备选举与四大核心职责
  5. InfiniBand 管理元素：SM / SMA / MADs 三角色
  6. 三层地址体系：GUID / LID / GID
  7. 分组发送：LID 分配与转发表编程
  8. OFED 工具集：驱动、HCA、子网连通性、路径追踪
  9. FAQ 高频问答（20 组）
  10. 知识小结（10 个知识点）
  11. Roadmap 后续预告

一、InfiniBand 架构分层与"管理"概念

InfiniBand 架构学习的核心定位

InfiniBand 是一个专门为高性能、低延迟数据传输设计的网络架构。

它的学习方法和我们熟悉的以太网是相通的——都是"分层模型"，但 InfiniBand 的 管理层是显式存在的（指 IB 有专门的子网管理器 SM 进程负责网络初始化、拓扑管理、故障监控，这些功能在 IB 架构中是独立且必需存在的组件），这一点和以太网 "管理层淹没在 SNMP/日志里" 的风格（指以太网的网络管理功能分散在 SNMP 协议、系统日志、命令行配置工具中，没有一个集中式的管理进程来主导网络初始化，网络可以"即插即用"地运行）有本质区别。

 

本单元的目标是：

      • 能够列出 InfiniBand 架构的各层级结构（What）
      • 掌握每个架构层的具体功能和作用（How）
      • 描述 InfiniBand 数据包的结构和数据流过程（How）
      • 概述用于监控子网的基本 OFED 实用工具（How）

1.1 五层架构与"服务关系"

InfiniBand 采用 五层架构 描述数据传输过程，每层具有特定功能、协议和设备。它的服务关系是一个经典的 "上层调用下层" 模型：

      • 每层为上层提供服务（Service），同时向下层发出服务请求（Request）
      • 每层协议独立：本层只关心自己头部/尾部的添加与解析
      • 分层模型：每层具有特定功能、协议和设备，InfiniBand 的设备有 HCA（主机通道适配器，属上层协议端）、交换机（属链路层设备）、路由器（属网络层设备）等

下面用一张 ASCII 图把五层架构、对应的设备、承担的职责完整列出来：

      ┌─────────────────────────────────────────────────────────────┐
        │  L5  上层协议层（Upper Layer Protocol）                       │
        │      └─ 协议：SRP / iSER / NFS-RDMA / RDMA / IPoIB ...       │
        │      └─ 设备：HCA（Host Channel Adapter）上的应用进程          │
        │      └─ 职责：把用户态消息（Send / RDMA Write / RDMA Read /   │
        │              Atomic）封装成数据包下发给传输层                  │
        ├─────────────────────────────────────────────────────────────┤
        │  L4  传输层（Transport）                                      │
        │      └─ 协议：传输层头部 BTH（Base Transport Header）          │
        │      └─ 职责：分段、重组、操作码（Send/RDMA 写/读/原子）       │
        │      └─ 关键字段：PSN（数据包序列号）、分区信息                │
        ├─────────────────────────────────────────────────────────────┤
        │  L3  网络层（Network）                                        │
        │      └─ 协议：网络层头部 GRH（Global Route Header）            │
        │      └─ 设备：路由器（Router）                                │
        │      └─ 职责：跨子网路由（基于 GID）                          │
        ├─────────────────────────────────────────────────────────────┤
        │  L2  链路层（Link）                                           │
        │      └─ 协议：链路层头部 LRH（Local Route Header）              │
        │      └─ 设备：交换机（Switch）                                │
        │      └─ 职责：子网内基于 LID 的转发、流量控制、CRC 校验        │
        ├─────────────────────────────────────────────────────────────┤
        │  L1  物理层（Physical）                                       │
        │      └─ 协议：物理编码（NRZ / PAM4 / 8b/10b 等）              │
        │      └─ 设备：线缆 / 光模块 / 收发器                          │
        │      └─ 职责：比特流传输、信号编码、电气特性                  │
        └─────────────────────────────────────────────────────────────┘

注意：五层 ≠ OSI 七层。OSI 七层模型把 "会话层 / 表示层" 独立出来，InfiniBand 是面向工程落地的网络架构，实际只有 5 层，没有显式的会话层和表示层——对应功能由应用层协议（如 SRP）自行实现。这一点在学习 InfiniBand 时非常关键，否则容易把会话层概念硬塞进去。

1.2 课程对五层职责的再次确认

课程视频在"知识小结"部分对各层职责做了完整总结，我们把它做成对照表，方便后续查阅：

层级名称核心职责
L1 物理层 信号传输和物理连接
L2 链路层 处理链路级通信和流量控制
L3 网络层 实现路由选择和网络寻址
L4 传输层 确保端到端可靠数据传输
L5 管理层 / 上层协议 提供网络配置和监控功能 / 协议消息封装

学习建议：建议按单元顺序系统学习各层知识，Unit 3 将重点讲解物理层细节，本单元对物理层只做"知道存在"的章节定位即可。

本节关键记忆：1 主线 + 5 层 + 1 关键差异

  • 1 个主线：InfiniBand 五层架构 = 物理层 + 链路层 + 网络层 + 传输层 + 上层协议
  • 5 层职责对应：物理层管信号、链路层管子网内转发、网络层管跨子网、传输层管端到端、上层协议管应用消息
  • 1 个关键差异：InfiniBand 五层 ≠ OSI 七层，没有显式会话层/表示层

二、InfiniBand 数据包结构：LRH / GRH / BTH / ETH 四层头部

读完这一节你必须能回答 "这四种头什么时候出现 / 标识什么"。这是后续学习抓包分析、QoS、网络排查的基石。

2.1 数据包基本单元与封装原理

InfiniBand 沿用 TCP/IP 体系的 "封装" 思想：上层协议消息被封装成数据包，各层添加相应头部和尾部。但它的数据包与以太网帧有几个关键差异，课程视频明确点出了两点：

      • 有效载荷大小：可路由的数据传输单元包含 256~4096 字节 的有效载荷（远超以太网 MTU 1500）
      • 校验机制：包含两个 CRC 校验（ICRC 和 VCRC）确保数据完整性

为什么是 256~4096 字节？这是 InfiniBand 协议规定的 "可路由 MTU" 范围。

      • 下限 256 字节保证了即使是 ACK/NAK 等小型控制报文也能独立成包；
      • 上限 4096 字节则让 RDMA 大块数据（如模型梯度）可以单包传输，减少分片开销。

对比以太网 MTU 1500（巨型帧 9000），IB 的 4096 是处于 "协议开销" 和 "传输效率" 之间的权衡值。

为什么需要两个 CRC？课程视频点出了 关键点：ICRC 校验不变字段，VCRC 校验可变字段。

      • IB 数据包在经过交换机转发时，VL（虚拟通道）字段可能被修改（用于拥塞控制），所以 VL 字段必须放在 VCRC 覆盖范围内；
      • 其他字段（LRH 中的 SL/LID/SL 等）不变，所以放在 ICRC 覆盖范围内。

这样只要 VL 改了，交换机就重算 VCRC，ICRC 仍然有效——这是一种 "分治校验" 设计。

2.2 四层头部的精确语义

课程视频对四个头部的出现条件、字段、用途做了精确区分，下面用表格做一次精解：

头部全称出现条件关键字段在哪种设备上解析
LRH Local Route Header（本地路由头） 始终存在 本地源/目的端口、SL（服务等级）、VL（虚拟通道） 交换机（L2）
GRH Global Route Header（全局路由头） 跨子网传输时存在 源 GID / 目的 GID 路由器（L3）
BTH Base Transport Header（基本传输头） 必选字段 操作码（Send / RDMA 写 / RDMA 读 / 原子操作）、PSN（数据包序列号）、分区信息 目的端 HCA（L4）
DETH Datagram Extended Transport Header（数据报扩展传输头） 只在不可靠数据报（UD）传输时存在，与 BTH 一起构成传输层头 队列对号 QPN / 源 EH（Ethernet Header）等 目的端 HCA
ETH Extended Transport Header（扩展传输头） 条件存在：根据服务类别和操作码决定 RDMA 操作的虚拟地址 / 远程键 / 原子操作数等 目的端 HCA

关于 DETH 和 ETH 的区分：课程视频原文在"数据包示例"一节写的是"传输层头（BTH+DETH）"，在"数据包结构"一节写的是"ETH（扩展传输头）"。

两者是不同的头部：

    • DETH 是 不可靠数据报（UD）传输层 的扩展头（与 BTH 一起位于 L4）
    • ETH 是 RC/RDMA 操作 的扩展头（承载 RDMA 虚拟地址、远程键等）

一句话区分：发不可靠数据报用 DETH，做 RDMA 操作才用 ETH。

VL（虚拟通道）这个字段值得特别强调：它在 LRH 中被指定，且VL 在子网内可变。交换机在转发时可以根据拥塞情况修改 VL，但不会改 LRH 的其他字段。这意味着 InfiniBand 的 "虚拟通道" 是链路层概念，而不是网络层概念——QoS 决策发生在链路层。

2.3 子网内数据包的"典型组成"

课程指出，通过流量监控工具可以捕获实际数据包。在子网内捕获的典型数据包组成如下：

子网内典型数据包结构（不跨子网）：
        ┌──────────────────────────────────────────┐
        │  LRH  链路层头（始终存在）                │  ← L2 交换机解析
        ├──────────────────────────────────────────┤
        │  BTH  传输层头（必选）                    │  ← L4 目的端 HCA 解析
        ├──────────────────────────────────────────┤
        │  DETH 扩展传输头（条件存在）              │  ← 操作码决定
        ├──────────────────────────────────────────┤
        │  MAD  管理数据报（如果是管理流量）        │  ← 由 SM 与 SMA 通信
        ├──────────────────────────────────────────┤
        │  Payload  有效载荷（256~4096 字节）       │
        ├──────────────────────────────────────────┤
        │  ICRC  校验不变字段                       │
        ├──────────────────────────────────────────┤
        │  VCRC  校验可变字段（含 VL 等）           │
        └──────────────────────────────────────────┘

关键观察：子网内没有 GRH。因为 GRH 只在数据包跨子网时才存在，ibtracert 抓到的子网内路径里看不到 GRH。这一点在学习抓包时非常容易踩坑——看到没有 GRH 不要以为是"协议缺失"，这正是 InfiniBand 的合理设计。

交换机处理的关键细节：课程视频在 "知识小结" 中明确指出交换机工作原理是 "基于 LID 的转发机制——查表确定出口端口，修改 VL 但不改其他字段"。

这是 IB L2 转发的精简化模型：交换机既不修改 LRH 的源/目的 LID，也不修改 SL 字段，只在拥塞控制需要时调整 VL 字段。这也正是 VL 属于 VCRC 覆盖范围（可变字段）的原因——因为 VL 在交换机处可能被改写，必须重新计算 VCRC。

2.5 数据包端到端流程

本节最核心的是 "一个数据包从发送到接收的全链路流程"。课程视频把它拆成三段（发送端 / 交换机 / 接收端），我们用 ASCII 时序图完整呈现：

发送端（Host A / HCA）                          交换机                          接收端（Host B / HCA）
        ─────────────────                              ─────                          ──────────────────
                        L5 上层协议：创建消息
                                      │
                                      ▼
                        L4 传输层：分段 + 添加 BTH
                                      │
                                      ▼
                        L3 网络层（可选）：跨子网才添加 GRH
                                      │
                                      ▼
                        L2 链路层：添加 LRH（含 SL/VL）+ CRC
                                      │
                                      ▼
                        L1 物理层：转换为比特流
                                      │
                                      ▼
                                                      L2 交换机：
                                                      ① 校验 CRC
                                                      ② 根据 LRH 确定出口端口
                                                      ③ 可能经过多级交换
                                                                      │
                                                                      ▼
                                                     L1 接收端：比特流恢复
                                                          │
                                                          ▼
                                                     L2 接收端：解析 LRH
                                                          │
                                                          ▼
                                                     L3 接收端（可选）：解析 GRH
                                                          │
                                                          ▼
                                                     L4 接收端：解析 BTH
                                                          │
                                                          ▼
                                                     L5 接收端：执行相应服务
                                                          │
                                                          ▼
                                                     ▲
                                      ▲ 重组分段载荷 + 恢复原始消息结构

本节关键记忆：1 思想 + 5 头部 + 3 段流程

  • 1 个核心思想：分层封装 = 层层加头（LRH 始终 + GRH 跨子网 + BTH 必选 + DETH 不可靠数据报用 + ETH RDMA 操作时用）
  • 5 个头部的出场顺序：LRH → (GRH) → BTH → (DETH 或 ETH) → Payload → ICRC → VCRC
  • 3 段流程：发送端封装 → 交换机转发（校验 + 查表 + 可能改 VL）→ 接收端解封装
  • 1 个易错点：交换机只改 VL，不改 LRH 其他字段；VL 属于 VCRC 覆盖范围

三、Fabric vs. Subnet：物理基础设施 vs. 管理实体

这是初学者最容易混淆的一对术语。课程视频开篇就强调："虽然 Fabric 和 Subnet 经常被混用，但两者具有不同含义。"

3.1 精确定义

二者的精确边界如下：

      • Fabric（物理基础设施）：由 链路（links）、交换机（switches）和路由器（routers）组成的集合，用于连接 一组通道适配器（channel adapters）。注意：Fabric 本身是"硬件集合"，不关心任何管理状态。
      • Subnet（子网，管理实体）：具有 共同子网 ID（common subnet ID）的端口及其关联链路的集合，并由 公共子网管理器（common subnet manager）统一管理。

3.2 关系与激活条件

二者关系是 "先有 Fabric，再被 SM 激活成 Subnet"：

      • 网络拓扑：不同子网之间可以通过路由器相互连接，形成更大的网络结构
      • 激活要求：一个 Fabric 必须经过子网管理器的 初始化和激活 才能成为可用的 Subnet，此时才允许流量转发

3.3 关系图（ASCII）

                           ┌──────────────────────────────────────────┐
                            │            Fabric（物理基础设施）         │
                            │   links + switches + routers + HCA 端口  │
                            └──────────────────────────────────────────┘
                                          │
                                          │  ① 相同 Subnet ID
                                          │  ② 相同 Subnet Manager 管理
                                          ▼
                            ┌──────────────────────────────────────────┐
                            │            Subnet（管理实体）             │
                            │   拥有 SM + 活跃 LID 转发表 + 流量转发权限 │
                            └──────────────────────────────────────────┘
                                          │
                                          │  多个 Subnet 通过 Router 互联
                                          ▼
                            ┌──────────────────────────────────────────┐
                            │            更大的 Fabric（多子网拓扑）     │
                            └──────────────────────────────────────────┘

本节关键记忆：1 个对比 + 1 个因果

  • 1 个对比：Fabric = 物理硬件的集合；Subnet = 拥有共同子网 ID 且被同一个 SM 管理的活跃实体
  • 1 个因果：Fabric 需要经过 SM 初始化才能"激活"为 Subnet；激活后才允许流量转发

四、子网管理器 SM：主备选举与四大核心职责

SM 是整个 InfiniBand 网络的"控制大脑"。课程视频对它的核心功能描述是："作为运行和管理 Fabric 的实体，提供集中式路由管理，实现网络中节点的即插即用（plug and play）。"

4.1 主备机制（Master / Standby）

SM 不止一个，它们共同工作，但只有一个是"主"。课程视频给出了完整的主备机制设计：

      • 选举机制：子网中可存在多个子网管理器，但仅选举一个作为主节点（master）
      • 故障转移：备用管理器 通过轮询监测主节点活动，主节点故障时自动选举新主节点
      • 部署建议：推荐运行 两个子网管理器（一主一备）确保高可用性

注意：1+1 是推荐但不是强制。课程视频原文写的是 "推荐运行两个"，并未强制要求。

理论上一个 SM 也能工作，但失去高可用性。

生产环境通常按 1 主 1 备进行部署，至少有两个 SM 节点以保障选举机制的正常工作。

4.2 四大核心职责

SM 在选举完成后，承担以下四类核心工作：

职责具体内容
1. 拓扑发现 自动发现网络拓扑结构（含新设备的加入、旧设备的离开）
2. 标识分配 为节点分配本地标识符（LID）
3. 路由计算 计算并编程交换机转发表
4. 状态监控 管理子网所有元素并监控变更

4.3 部署灵活性

SM 作为软件解决方案，可部署在服务器、交换机或专用设备等任意网络节点上。课程视频原文表述为"作为软件解决方案，可部署在服务器、交换机或专用设备等任意网络节点上"，没有对硬件形态做任何限制。

How —— 站在运维视角看 SM 的"双重角色"

视角 1：SM 是"集中式控制器"，违背了以太网去中心化传统

以太网交换机的转发表是"自学习"的（源地址学习 + 老化），但 InfiniBand 走了相反路线——完全由 SM 集中计算并下发。这就意味着：

      • ① 没有 SM，交换机就没有转发表，流量无法转发（即使所有硬件物理连通）
      • ② SM 重启会触发全网转发表重算（短暂中断）
      • ③ SM 故障是单点故障——必须用主备机制兜底

视角 2：SM 的"即插即用"是 L2 协议的工程胜利

SM 通过拓扑发现自动识别新上线的 HCA/Switch，并自动分配 LID、编程转发表。这就是即插即用（plug and play）的来源——管理员无需像以太网那样逐台配置 VLAN / 静态 MAC 表。注意这个能力 高度依赖 SM 能持续运行，没有 SM，"即插即用" 就退化为 "即插即停"。

视角 3：主备选举机制 + 轮询监控 = 故障时自动切换

课程视频精确指出 "备用管理器通过轮询监测主节点活动，主节点故障时自动选举新主节点"。这意味着主备切换是一个 "自动 + 异步" 的机制：备用不间断轮询，发现主节点失联便发起选举。

生产上需要关注业务对切换延迟的容忍度——例如 RDMA 训练任务对短暂中断可能无感，但分布式存储对 SM 切换更敏感。

汇总：SM 的 3 个工程特性

      • 1 个集中式控制：所有转发表由 SM 编程
      • 1 个即插即用能力：拓扑发现 + 自动分配 LID + 自动编程转发表
      • 1 个高可用机制：主备选举 + 轮询监控（自动故障转移）

本节关键记忆：1 主 1 备 + 4 职责 + 1 部署

  • 1 主 1 备：SM 主备选举，靠轮询监控实现自动故障转移
  • 4 职责：拓扑发现 / LID 分配 / 路由计算 / 状态监控
  • 1 部署灵活性：SM 是软件，可装在服务器、交换机或专用设备上

五、InfiniBand 管理元素：SM / SMA / MADs 三角色

理解 InfiniBand 管理模型，需要分清楚三个角色：SM、SMA、MAD。 课程视频对它们做了精确定义：

5.1 子网管理器（SM）

SM 是主动实体，负责发送命令和查询请求，是整个子网的 管理核心。

5.2 节点定义

节点 指 任何受管理的实体，包括：

      • 交换机（如 SW-A 到 SW-E）
      • 主机通道适配器（HCA）
      • 路由器
      • 其他硬件设备

小白理解节点：在 InfiniBand 中，"节点"是一个逻辑概念，不一定指"一台服务器"。

一个物理交换机是一个节点，一个 HCA 端口也是一个节点。

SM 在拓扑发现时把每个节点当作一个独立单元管理，统一分配 LID、统一监控状态。

5.3 代理机制（SMA）

节点必须 运行子网管理器代理（SMA）才能与 SM 通信。代理有以下特征：

        • 通常是被动的，响应管理器的查询
        • 在 必要时也能主动发送 trap 消息 引起管理器注意

5.4 通信协议（MADs）

管理器与代理之间通过 管理数据报（MADs，Management Datagrams）进行通信，这是 标准化的消息格式。MAD 的两层特性：

        • 标准化：MAD 是 IBTA 标准定义的报文格式，不同厂商的设备都能互通
        • 走数据通路：MAD 报文也通过 InfiniBand 数据包承载（属于一种特殊的上层协议）

5.5 三角色协作图（ASCII）

                         ┌──────────────────────────┐
                         │  Subnet Manager (SM)     │  ← 主动实体
                         │  发送命令和查询请求        │
                         └────────────┬─────────────┘
                                      │
                                      │  MAD（管理数据报）
                                      │
                      ┌───────────────┼───────────────┐
                      │               │               │
                      ▼               ▼               ▼
             ┌────────────────┐  ┌────────────────┐  ┌────────────────┐
             │  SW-A 交换机    │  │  HCA 主机适配器 │  │  Router 路由器 │
             │  SMA 代理（被动）│  │  SMA 代理（被动）│  │  SMA 代理（被动）│
             └────────────────┘  └────────────────┘  └────────────────┘
                ▲                       ▲                       ▲
                │  必要时主动 trap      │                       │
                └───────────────────────┴───────────────────────┘

本节关键记忆：1 主动 + 1 标准 + 1 双向

  • 1 主动角色：SM 是主动发送命令/查询的一方
  • 1 标准协议：SM 与 SMA 通过 MADs（标准化管理数据报）通信
  • 1 双向通信：SMA 通常被动响应查询，但必要时可主动 trap（如链路断开）

六、三层地址体系：GUID / LID / GID

地址体系是 InfiniBand 比以太网"复杂得多"的一处。以太网本质只有 MAC（类似这里的 GUID），而 InfiniBand 有三层地址体系，每种地址在特定网络层级发挥作用。

6.1 全局唯一标识符（GUID）

GUID 是一个硬件固化身份：

      • 硬件固化：由厂商烧录到硬件中的永久性地址，重启后保持不变
      • 应用范围：用于标识子网内所有元素，包括 机箱、HCA、交换机、路由器和端口 等物理设备
      • 特性：保证全球唯一性，是设备最底层的身份标识（类似以太网的 MAC 地址）

6.2 本地标识符（LID）

LID 是 子网内动态分配的短地址：

      • 分配机制：由子网管理器动态分配，仅在当前子网内有效
      • 报文处理：出现在本地路由头（LRH）中，包含源和目的 LID，交换机据此在子网内进行数据包转发

6.3 全局标识符（GID）

GID 是 跨子网通信的身份：

      • 功能定位：用于标识终端端口或多播组，支持跨子网的全局通信
      • 路由机制：出现在全局路由头（GRH）中，路由器根据目的 GID 在不同子网间转发数据包
      • 唯一性保证：与 GUID 不同，GID 需要在多个子网范围内保持唯一性

6.4 三层地址对照表

地址来源范围出现位置使用者
GUID 厂商烧录 全球唯一 SMA 通讯 / 拓扑发现 SM 识别设备
LID SM 动态分配 子网内唯一 LRH（本地路由头） 交换机转发
GID 由 GUID 派生 / 分配 跨子网唯一 GRH（全局路由头） 路由器转发

课程的精确表述："与 GUID 不同，GID 需要在多个子网范围内保持唯一性。"这意味着 GID 的分配需要全网协调（通常由 SM 协调），不能简单地"每设备一个 GID"——因为多子网环境下不同设备的 GID 可能冲突。生产中通常一个 GID 由 GUID + 子网前缀 派生，由 SM 统一管理。

How —— 站在协议栈视角看三层地址的设计哲学

视角 1：地址的 "作用域" 决定了它的位置

        • GUID 是"全球唯一"——用于 SM 在拓扑发现阶段识别"哪台设备是新加入的"
        • LID 是"子网内唯一"——装在 LRH 中，交换机据此做查表转发
        • GID 是"跨子网唯一"——装在 GRH 中，路由器据此在不同子网间转发

视角 2：LID 是 "为转发效率服务的" 压缩地址

课程视频强调 LID 是"本地标识符"，仅在当前子网内有效。

交换机要做子网内转发，需要一个 "短而快" 的地址——LID 的设计目的就是塞进 LRH 实现线速查表，所以它是 "子网内紧凑" 的短地址。

LID 短带来的代价是 "子网内必须唯一"，所以 SM 需要动态分配并避免冲突。

视角 3：GID 是 "为跨子网唯一性服务的" 扩展地址

课程视频原文："GID 用于标识终端端口或多播组，支持跨子网的全局通信"。

这意味着 GID 不能只在本子网内有效，必须在多个子网范围内保持唯一性——这是和 GUID 的本质区别（GUID 仅用于识别设备身份，不参与跨子网路由）。

SM 在初始化时负责 GID 的协调分配，避免多子网环境下冲突。

汇总：3 种地址的 3 个设计原则

      • 1 个硬件固化：GUID 厂商烧录，启动不变（用于拓扑发现）
      • 1 个本地压缩：LID 由 SM 动态分配，仅子网内有效（用于 LRH 转发）
      • 1 个全局扩展：GID 跨子网唯一，由 SM 协调分配（用于 GRH 路由）

本节关键记忆：1 个三层 + 3 个范围

  • 1 个三层：GUID（硬件） / LID（子网内） / GID（跨子网）
  • 3 个范围：全球唯一 / 子网内唯一 / 跨子网唯一
  • 3 个使用位置：GUID 用于拓扑发现 / LID 用于 LRH / GID 用于 GRH

七、分组发送：LID 分配与转发表编程

这一节是"SM 的工作细节"——把 SM 的"路由计算"职责具体化。课程视频给出了一个具体示例：子网中有 SW-A、SW-B、SW-C、SW-D、SW-E、SW-F 等多个交换机，SM 给每个管理节点分配 LID，并编程所有交换机的转发表。

7.1 LID 分配机制

子网管理器在初始化阶段或检测到拓扑变化时，会为子网中的每个管理节点分配一个 LID（Local Identifier）。例如：

      • SW-A 被分配 LID 2
      • SW-B 被分配 LID 1
      • 其他节点依此类推

课程视频的 LID 分配原则：LID 是"本地标识符"，仅在当前子网内有效。这意味着：

    • 同一子网内不能有两个节点拥有相同 LID（否则交换机转发会冲突）
    • 不同子网可以有相同的 LID（互不影响，因为不同子网用 GID 路由）
    • SM 在初始化时按"先到先得"或预设规则分配，节点拔出后该 LID 可被回收

7.2 转发表编程

子网管理器计算并编程交换机转发表，建立 目标 LID 与出口端口的映射关系。例如：

      • SW-A 的转发表中：LID 5 → 端口 1
      • SW-A 的转发表中：LID 3 → 端口 3

7.3 分组转发流程

交换机收到数据包时，按以下流程转发：

      1. 匹配机制：交换机收到数据包时，会提取目标 LID 并在转发表中进行匹配
      2. 端口选择：根据转发表中的映射关系确定出口端口，如目标 LID 11 的数据包将从端口 1 转发
      3. 最佳路径：子网管理器会计算最优路径（如 SW-A 到 SW-C 的最佳路由经过端口 1），并据此编程转发表

7.4 动态更新特性

当网络拓扑发生变化时，子网管理器会 重新分配 LID 并更新所有交换机的转发表，确保路由信息始终保持最新状态。这是 "即插即用" 的具体实现路径。

具体来看，"动态更新" 会在以下场景触发：

      • 新设备上线：HCA / 交换机 / 路由器插入网络，SM 拓扑发现后自动分配 LID
      • 设备下线：设备被拔出或故障，SM 重新计算并更新转发表
      • 链路状态变化：物理链路 up/down，SM 重算最佳路径
      • SM 重启：主备切换时，新的 Master 重新执行全网拓扑发现

小白注意：所有这些"动态更新"都是 SM 自动完成的，管理员无需手动介入。

这和以太网 VLAN / 静态 MAC 表的手工配置形成鲜明对比——IB 网络对运维友好的一面就来自于 SM 的中央控制设计。

7.5 转发表与转发的 ASCII 全景图

SM（子网管理器）                  SW-A（Leaf 交换机）
          │                              │
          │  ① 分配 LID：                 │  ③ 编程转发表：
          │   SW-A → LID 2               │     LID 5 → 端口 1
          │   SW-B → LID 1               │     LID 3 → 端口 3
          │   SW-C → LID 5               │     LID 11 → 端口 1
          │   ...                        │     ...
          │                              │
          │  ② 计算最优路径              │
          │   SW-A → SW-C 走端口 1        │
          ▼                              ▼
          数据包到达 SW-A：LRH 里的目标 LID = 5
          → 交换机查表：LID 5 → 端口 1
          → 从端口 1 转发到 SW-C

本节关键记忆：1 分配 + 2 编程 + 1 动态

  • 1 分配：SM 为每个管理节点（LID）
  • 2 编程：转发表 = 目标 LID → 出口端口
  • 1 动态：拓扑变化时 SM 重新分配 LID + 重新编程转发表

八、OFED 工具集：驱动、HCA、子网连通性、路径追踪

OFED（OpenFabrics Enterprise Distribution）是 InfiniBand 运维的 "瑞士军刀"。

课程视频对它的定义是："用于 RDMA 和内核旁路应用的开源软件栈。"——这句话里有两个关键信息：① 它是开源；② 它服务于 RDMA 和内核旁路 两类应用。

8.1 OFED 的版本演进

版本说明
MLNX_OFED 由 NVIDIA（曾用名 Mellanox）测试打包的版本，支持 InfiniBand 和以太网设备，使用相同的 OFED Verbs 内核旁路 API
DOCA-OFED MLNX_OFED 的新替代品，包含相同的驱动程序和工具，并通过 DOCA 增强可编程性

课程视频示例中显示版本 24.07-0.6.1（DOCA-OFED 形式）。

8.2 驱动信息命令

OFED 工具集的功能体现为 "提供控制、管理和诊断 InfiniBand 网络的实用工具"。课程视频在 "InfiniBand 驱动程序信息" 小节给了两条命令：

      • 查看版本：ofed_info——显示当前 DOCA-OFED 驱动版本（如示例显示版本 24.07-0.6.1）
      • 检查状态：/etc/init.d/openibd status——检查驱动是否运行，并列出关键模块（rdma_ucm / rdma_cm / ib_ipoib / mlx5_core 等）

小白理解这两个命令：

      • ofed_info 用来 "知道装的是什么"——版本号决定了你后续能用的功能
      • /etc/init.d/openibd status 用来 "知道驱动有没有跑"——如果没跑，后续所有 IB 工具都会失败
      • 如果状态显示未运行，需手动启动服务：/etc/init.d/openibd start

8.3 HCAs 信息检测

课程视频给出的检测命令是 lspci | grep -i Mellanox，用于识别主机通道适配器。

示例输出显示 ConnectX-6 双端口 HCA（每行显示一个端口）。这一步是"硬件验证"——确认 HCA 已安装且驱动正常运行。

常见命令组合：排查 HCA 问题时通常先看 lspci（物理识别），再看 ibstat（逻辑状态），最后看 dmesg | grep mlx（驱动日志）。三步齐全才能定位 "硬件 / 驱动 / 状态" 三类问题。

8.4 本地 InfiniBand 信息：ibstat

ibstat 是最常用的命令之一，输出内容包括：

        • CA 类型（如 MT4123）
        • 固件/硬件版本
        • 端口状态（需确认状态为 Active 且 Physical state 为 LinkUp）
        • 速率（如 100Gbps）
        • GUID 和 LID 信息

两个容易混淆的状态字段：

  • State：逻辑状态——INIT、ARMED、Active 等。"Active" 表示端口已激活可通信
  • Physical state：物理状态——LinkUp、Polling 等。"LinkUp" 表示物理链路连通

排查时两者都要看：Physical state = LinkUp 是物理层正常，State = Active 是协议层正常。两者缺一不可。

使用 ibstat -h 可查看特定 HCA 和端口的详细信息——这是排查 "某个端口为什么没起来" 时常用的高级选项。

8.5 验证第二层连接：ibping

ibping 是一个客户端-服务器架构的连通性测试工具，需同时在源主机和目标主机运行：

        • 服务器端：ibping -S（监听模式）
        • 客户端：ibping -L <目标 LID>（如示例 LID 18）

小白操作步骤：

  1. 在 目标主机 开一个终端跑 ibping -S（进入监听模式）
  2. 在 源主机 开另一个终端跑 ibping -L 18（假设目标 LID 是 18）
  3. 源端每发一个包，目标端会回一个 "pong"，源端能持续收到 pong 说明 L2 连通

如果收不到 pong，可能原因：① 目标端未启动监听；② LID 错误；③ SM 未给目标分配 LID；④ 物理链路故障。

课程视频明确提醒："显示时间不可用于延迟测量，需专用工具。"虽然 ibping 会显示一个时间戳，但这个时间不代表真实的 RTT 延迟——它是协议栈时间戳，不是 ICMP 那种往返时延。要测 RDMA 延迟，需要使用 ib_send_bw / ib_write_bw 等 perftest 工具。

8.6 路径追踪：ibtracert

ibtracert 用于追踪源 LID 到目标 LID 的路径。它显示的信息包括：

        • 设备名称（如 leaf9/spine7）
        • 端口号
        • GUID 和 LID

课程视频原文："追踪源 LID 到目标 LID 的路径"，并指出"可从任意节点发起"——这是工具自身的设计特点，使运维可以从旁观节点发起排查。典型路径示例：

        • 源主机端口（LID 13）
        • 连接的 leaf 交换机（leaf9）
        • spine 交换机（spine7）
        • 目标 leaf 交换机（leaf10）
        • 目标主机端口（LID 18）

小白理解路径追踪：ibtracert 输出的"路径"是 SM 编程的转发表结果——也就是说，它显示的是"数据包实际会走哪条路"，而不是"物理线缆连接"。如果某条物理链路 down 了，SM 会重算路径，ibtracert 输出会立即反映新路径。

8.7 OFED 工具集中命令一览表

命令用途关键输出
ofed_info 查看版本 如显示版本 24.07-0.6.1
/etc/init.d/openibd status 检查驱动运行状态 关键模块：rdma_ucm / rdma_cm / ib_ipoib / mlx5_core
lspci | grep -i Mellanox 识别主机通道适配器 如 ConnectX-6 双端口 HCA
ibstat 本地 IB 设备状态 CA 类型 / 速率 / GUID / LID
ibping 第二层连通性测试 "pong" 响应
ibtracert 路径追踪 沿途 Leaf / Spine 名称、端口、GUID、LID

8.8 综合诊断五步法

结合课程视频中的命令，我们给出一个"自下而上"的诊断流程：

      1. 看版本：ofed_info — 确认驱动版本
      2. 看驱动：/etc/init.d/openibd status — 确认驱动已加载
      3. 看硬件：lspci | grep -i Mellanox — 确认 HCA 已被识别
      4. 看本地：ibstat — 确认端口 LinkUp 且有 LID
      5. 看连通 + 路径：ibping / ibtracert — 确认子网内可通 + 路径符合预期

本节关键记忆：1 个工具栈 + 2 个版本 + 6 个命令

  • 1 个工具栈：OFED = 开源软件栈，服务 RDMA 和内核旁路
  • 2 个版本：MLNX_OFED（NVIDIA 测试版） / DOCA-OFED（MLNX_OFED 的新替代）
  • 6 个命令：ofed_info / openibd status / lspci / ibstat / ibping / ibtracert
  • 1 个注意：ibping 显示的时间不可用于延迟测量

九、FAQ 高频问答（20 组）

本节围绕 InfiniBand 架构入门梳理 20 个高频易错点，题目在课程视频中均有原型依据。

Q1. InfiniBand 是几层架构？和 OSI 模型什么关系？

InfiniBand 采用 5 层架构（物理层 / 链路层 / 网络层 / 传输层 / 上层协议），不是 OSI 7 层。InfiniBand 没有显式的会话层和表示层，对应功能由上层协议（如 SRP）自行实现——这是初学者最容易踩的坑，硬把 OSI 概念塞进去会导致协议理解错位。

Q2. 物理层 / 链路层 / 网络层 / 传输层 / 上层协议各干什么？

物理层管信号、链路层管子网内转发、网络层管跨子网、传输层管端到端、上层协议管应用消息。这是最精简的一句话总结，详细对应关系见第二节的表格。

Q3. LRH 和 GRH 什么时候出现？

LRH 始终存在，GRH 只在跨子网传输时存在。两者都不会"按需"切换——LRH 是所有 IB 数据包必备的本地路由头，GRH 是跨子网时才出现的全局路由头。

Q4. BTH 是必选吗？它包含哪些关键字段？

BTH 是基本传输头，必选字段。包括操作码（操作类型 Send / RDMA 写 / RDMA 读 / 原子操作）、数据包序列号（PSN）和分区信息。操作码是目的端 HCA 识别"这条消息要做什么"的关键字段。

Q5. ETH（扩展传输头）在什么时候出现？

ETH 根据服务类别和操作码决定是否出现。比如 RDMA 写操作需要承载远程虚拟地址 + 远程键，这些信息就放在 ETH 中；如果只是普通 Send 消息，ETH 可以省略。

Q6. InfiniBand 数据包的有效载荷有多大？

可路由的数据传输单元包含 256~4096 字节的有效载荷。这远大于以太网 MTU 的 1500 字节，是 InfiniBand 适合大块数据传输（如模型梯度同步）的物理基础之一。

Q7. 数据包里有几个 CRC？分别校验什么？

InfiniBand 数据包包含两个 CRC 校验：ICRC 和 VCRC。ICRC 校验不变字段，VCRC 校验可变字段。VL 在子网内可变，所以它属于 VCRC 覆盖范围。学习时把它们理解为"内层校验 + 外层校验"的双保险机制即可。

Q8. 交换机处理数据包的三个动作是什么？

交换机处理三件事：① 校验 CRC；② 根据 LRH 确定出口端口；③ 可能经过多级交换。注意交换机不修改 LRH 的其他字段，只修改 VL——这是 L2 转发的简化模型，只换数据通道，不动路由字段。

Q9. Fabric 和 Subnet 的区别是什么？

Fabric 是物理基础设施（link + switch + router），Subnet 是管理实体（拥有共同子网 ID 并被同一个 SM 管理）。Fabric 必须经过 SM 初始化才能激活为 Subnet，激活后才有流量转发权限。两者经常被混用，但精确边界是"硬件 vs. 管理状态"。

Q10. 多个 Subnet 之间如何连接？

不同子网之间通过路由器相互连接，形成更大的网络结构。路由器工作在网络层（L3），使用 GRH 中的 GID 进行跨子网转发。

Q11. 子网管理器有几个？必须主备吗？

子网中可存在多个子网管理器，但仅选举一个作为主节点（master）。课程视频推荐运行两个（一主一备）以确保高可用性。注意这是"推荐"不是"强制"——理论上一个 SM 也能工作，但失去高可用性。

Q12. 主备切换是怎么发生的？

备用管理器通过轮询监测主节点活动，主节点故障时自动选举新主节点。这是"软实时"切换（毫秒级~秒级延迟），不是硬实时零中断。RDMA 训练任务对秒级中断可能无感，但部分分布式存储对切换延迟更敏感。

Q13. SM 的四大核心职责是什么？

拓扑发现 / 标识分配 / 路由计算 / 状态监控。具体来说就是：自动发现网络拓扑、为节点分配 LID、计算并编程交换机转发表、管理子网所有元素并监控变更。这四件事的协同保证了"即插即用"。

Q14. SM 软件可以部署在哪里？

SM 作为软件解决方案，可部署在服务器、交换机或专用设备等任意网络节点上。课程视频原文表述。SM 没有硬件形态的强制要求——可以运行在普通服务器上（作为宿主进程），也可以跑在专用设备上。生产部署时通常选择 1 主 1 备两台机器以实现高可用。

Q15. 节点、SMA、SMA 的被动性分别是什么？

节点是任何受管理的实体（交换机 / HCA / 路由器等）；SMA 是节点上必须运行的代理；SMA 通常被动响应查询，但必要时可主动发送 trap 消息。理解"被动为常态、主动为例外"是掌握 SM/SMA 模型的关键。

Q16. MAD 是什么？

MAD（Management Datagram）是管理器与代理之间通信的标准化的消息格式。它是 IBTA 标准定义的报文格式，跨厂商互通；同时它本身也是通过 InfiniBand 数据包承载的（一种特殊的上层协议）。

Q17. GUID / LID / GID 三种地址的区别？

GUID 是厂商烧录、全球唯一的硬件身份；LID 是 SM 动态分配的本地标识符（仅在当前子网内有效）；GID 是跨子网唯一的全局标识符（支持多子网通信）。三者的精确分工是：GUID 用于拓扑发现 / LID 用于 LRH / GID 用于 GRH。

Q18. LID 为什么只能"子网内有效"？

LID 是"为子网内转发服务的"压缩地址。课程视频原文："LID 由子网管理器动态分配，仅在当前子网内有效"，并出现在本地路由头（LRH）中，交换机据此在子网内进行数据包转发。LID 短的目的是塞进 LRH 数据包头，让交换机可以基于 LID 实现子网内查表转发。短地址的代价是"子网内必须唯一"，所以需要 SM 动态分配避免冲突；它不能跨子网使用——跨子网必须用 GID。

Q19. GID 如何保证跨子网唯一性？

GID 通常由"子网前缀(64) + GUID(64)"派生，由 SM 统一管理。64 bit 的子网前缀由 SM 协调分配，64 bit 的 GUID 由厂商烧录，两个组合后天然具备跨子网唯一性。

Q20. ibping 显示的时间可以用来测延迟吗？

不可以。课程视频明确指出"显示时间不可用于延迟测量，需专用工具"。ibping 的时间戳是协议栈时间，不是 RTT。如果需要测 RDMA 延迟，使用 ib_send_bw / ib_write_bw 等 perftest 工具。

FAQ 总纲（口诀式速记）

  • 5 层架构：物理 + 链路 + 网络 + 传输 + 上层协议（非 OSI 7 层）
  • 5 头出场：LRH 始终 + GRH 跨子网 + BTH 必选 + DETH 不可靠数据报用 + ETH RDMA 用
  • 2 校验：ICRC 不变 + VCRC 可变（含 VL）
  • 1 主 1 备：SM 主备选举 + 轮询监控
  • 3 地址：GUID 全球 / LID 子网内 / GID 跨子网
  • 1 转发：交换机按 LRH 改 VL，不改其他字段

九、知识小结（来自课程视频原文）

下面包含 9 个知识点对应本单元的所有核心考点，每条都标注了难度系数（★★★☆☆=易，★★★★☆=难），方便小白读者自评掌握程度。

知识点核心内容技术要点难度系数
InfiniBand 架构分层 数据通信分层模型 每层提供特定功能和服务接口 ★★★☆☆
数据包结构 LRH / GRH / BTH 分层头结构 LRH 标识本地端口，GRH 用于跨子网路由 ★★★★☆
子网管理 子网管理器主备选举机制 拓扑发现 / LID 分配 / 路由表计算 ★★★★☆
地址体系 GUID / LID / GID 三级寻址 GUID 硬件固化，LID 子网内唯一，GID 全局路由 ★★★☆☆
OFED 工具包 ibstat / ibping / ibroute 诊断工具 设备状态检查 / 连通性测试 / 路径追踪 ★★★★☆
数据包流转 端到端传输流程 分层封装 → 交换机转发 → 目的端解封装 ★★★★☆
子网初始化 物理网络激活条件 必须通过子网管理器初始化才能通信 ★★★☆☆
管理数据单元 MAD 报文格式 标准化的管理器-代理通信协议 ★★★★☆
交换机工作原理 基于 LID 的转发机制 查表确定出口端口，修改 VL 但不改其他字段 ★★★★☆
CRC 校验机制 双校验位设计 ICRC 校验不变字段，VCRC 校验可变字段 ★★★★☆

如何使用这张知识小结表：

  • ★★★☆☆ 三条：架构分层、地址体系、子网初始化——属于"理解概念"层面，建议先掌握
  • ★★★★☆ 七条：数据包结构、SM 主备、OFED 工具、数据包流转、MAD、交换机原理、CRC——属于"工程细节"层面，建议动手实验后再深入
  • 难度系数和重点章节对应：★★★★☆ 多集中在第二、四、六、七、八节（数据包 / SM / 地址 / OFED）

十、Roadmap 后续预告

本篇是 InfiniBand 专题的第一篇，定位为 "架构入门"。后续单元将沿着 NVIDIA 官方视频课程 逐层深入，重点关注以下方向：

        • Unit 3 物理层细节：深入到 NRZ / PAM4 编码、信号整形、链路训练、Pre-emphasis 等物理层电气特性
        • 子网初始化与 SM 选举流程：从 SM 启动到 LID 分配到转发表编程的完整时序
        • QoS 与 VL 调度：VL 的虚拟通道机制、信用计数器（Credit-Based Flow Control）
        • RDMA 协议族：RDMA Send / Write / Read / Atomic 四类操作的语义差异、性能对比
        • IPoIB 与以太网桥接：InfiniBand 承载 IP 流量时的协议栈映射
        • Subnet Manager 高可用：主备切换的延迟控制、配置同步、避免脑裂

如果你在学习过程中遇到具体问题（例如 ibstat 输出异常、SM 选举失败、跨子网路由不通），欢迎在评论区留言，我会挑出共性问题单独扩展一篇专题。

本文参考与资料链接：

  • OFED 工具集：见 NVIDIA DOCA / OFED 官方文档

InfiniBand 专题【左扬精讲】· 第 2 单元：InfiniBand 架构简介

posted @ 2026-08-03 23:38  左扬  阅读(26)  评论(0)    收藏  举报