InfiniBand 专题【左扬精讲】—— InfiniBand 拓扑与路由引擎：Fabric 拓扑、路由引擎、自适应路由与信用环

InfiniBand 专题【左扬精讲】—— InfiniBand 拓扑与路由引擎：Fabric 拓扑、路由引擎、自适应路由与信用环

子网激活之后，让数据"真的能跑"的，是拓扑与路由。本系列上一篇《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》讲清楚了 SM 如何在子网激活阶段计算路径并写入每台交换机的转发表（LFT），但绕开了一个更前置的问题：SM 拿哪一套算法去算这些路径？这套算法是不是适用于当前的 fabric 拓扑？这两个问题共同构成了"路由引擎（Routing Engine）"与"fabric 拓扑"的耦合关系——也是本篇要展开的主线。

InfiniBand 的 fabric 不是 Ethernet 意义上的 L2/L3 自由路由网络。在 IB 里，转发表是 SM 在初始化阶段集中算好、下发到每台交换机硬件的，运行期基本不依赖分布式协议。这意味着两件事：第一，fabric 拓扑一旦确定，能跑的路由算法就基本确定了——算法与拓扑的兼容性是必须先验证的；第二，一旦算法选定，每次拓扑变化触发的"重算"都以同一种算法重新计算——算法的稳定性决定了重收敛时间。这两层关系都集中在"路由引擎"这一类参数上。

本篇是 InfiniBand 专题【左扬精讲】 系列的 第 10 篇。本篇是 Roadmap 上接续前九篇之后，从"子网建立 → 持续运行 → 数据怎么被转发"这一条主线的关键扩展。前九篇覆盖了分层、地址、子网管理角色、初始化流程、运行期维护，本篇第一次深入 "运行期的转发"本身：先讲 fabric 拓扑的设计考量与常见结构（leaf-spine、fat tree、Dragonfly+、3D Taurus），再讲 自适应路由（Adaptive Routing，AR） 这种"同一目的 LID 多条端口可用"的负载均衡机制，最后落到 信用环（Credit Loops） 这类"无损网络里的死锁陷阱"，并以 Up/Down 路由引擎 为示例，串起"拓扑 ↔ 路由引擎 ↔ 避免死锁"这条闭环。

本篇的核心命题只有一句：InfiniBand fabric 的"高性能"不是某一种拓扑或某一种算法单独给的，而是"拓扑 + 路由引擎 + 链路层流控"三者相互约束后达到的联合最优。读懂了这条主线，"为什么 fat tree 必须配 Min Hop / Up/Down 而 Dragonfly+ 必须配 AR"，"为什么过订阅比 1:1 的非阻塞 fat tree 反而在某些场景比 2:1 阻塞 fabric 慢"，"为什么 3D Taurus 在超大规模上比 fat tree 便宜得多"，就有了确定的解读路径。

本篇核心术语：
Fabric Topology fabric 拓扑 / Physical Topology 物理拓扑 / Logical Topology 逻辑拓扑
Leaf-Spine 叶子-脊骨架构 / Spine 脊骨层 / Leaf 叶子层 / Super Spine 超级脊骨
Fat Tree 胖树 / Over-Subscription Ratio 过订阅比 / Blocking / Non-Blocking 阻塞 / 非阻塞
Dragonfly+ 龙鳞拓扑 / Group / All-to-All / Bipartite Topology 二部图拓扑
3D Taurus 三维环面 / x-ring / y-ring / z-ring / Locality 局部性
Routing Engine 路由引擎 / Up/Down Algorithm Up/Down 算法 / Min Hop 最小跳数
Adaptive Routing (AR) 自适应路由 / LFT Linear Forwarding Table 线性转发表
Credit-Based Flow Control 基于信用的流控 / Credit Loop 信用环 / Deadlock 死锁
OpenSM opensm 用户态守护进程 / opensm.conf / routing_engine / -R

本篇核心命令：opensm -R up-down / opensm -R minhop / cat /etc/opensm/opensm.conf

本篇权威依据：IBTA Vol 1 Release 1.3.4（An InfiniBand Architecture Specification, Release 1.3.4, 2020）
rdma-core include/rdma/ib_mad.h 与 include/rdma/ib_smi.h
Linux 内核 drivers/infiniband/core/sa.c SM 路径选择
OpenSM 用户手册 opensm(8) man page 与 doc/OpenSM_UM.pdf

InfiniBandFabric 拓扑Leaf-SpineFat Tree过订阅比Dragonfly+3D Taurus路由引擎Up/DownMin Hop自适应路由AR信用环Credit LoopOpenSMrouting_engine

★ 学完这一篇你能掌握什么（渐进式路径：1→2→3→4→5 不可跳跃）

  • 第 1 步 · 拓扑设计（第一节、第二节）
      • What：网络拓扑的定义——物理拓扑描述设备如何连接，逻辑拓扑描述数据如何流动。两者是 fabric 设计的两个独立维度
      • How：能列出 fabric 拓扑设计的 5 类关键考量——可用性、可靠性、性能、未来扩展性、预算
      • Why：理解 "为什么 IB fabric 几乎都遵循 leaf-spine"——因为 IB 的目标场景（HPC / AI / 云原生）对低延迟、确定跳数、横向扩展、冗余同时提出硬性要求，leaf-spine 是同时满足这四点的最简结构
  • 第 2 步 · 常见 IB 拓扑（第三节、第四节、第五节、第六节）
      • What：Fat Tree（含过订阅比）/ Dragonfly+ / 3D Taurus 四种 IB fabric 主流拓扑——以及每种对应的"典型应用场景 + 主要优缺点"
      • How：能复述每种拓扑的典型跳数路径与带宽瓶颈位置——fat tree 三跳 / Dragonfly+ 组内一跳组间两跳 / 3D Taurus 沿三轴环面最多三维跳数
      • Why：理解 "为什么不同拓扑对应不同路由引擎"——fat tree 用 Min Hop / Up/Down（确定性、无环）；Dragonfly+ 必须配 AR（多路径需要动态选择）；3D Taurus 适合 Up/Down（环面内确定性高）
  • 第 3 步 · 自适应路由（第七节）
      • What：AR = 自适应路由——SM 把"通向同一目的 LID、且跳数相同"的多个出口端口同时写入 LFT，交换机在每条流上动态选择最不拥塞的端口
      • How：能描述 AR 的"端口组"概念——同 cost 端口进入同一组；以及 AR 触发重选的条件——端口故障 / 拥塞
      • Why：理解 "为什么 AR 比确定性 / 遗忘式路由（oblivious）在非均匀流量下表现更好"——前者把"拥塞感知"做到每包；后两者一旦路径选定就锁死，对突发流量不友好
  • 第 4 步 · 信用环与死锁（第八节）
      • What：Credit Loop = 在无损信用流控下，若一组交换机的入向缓冲区形成闭合环，则该环上所有缓冲区最终会被填满，导致整环死锁——不重启无法恢复
      • How：能复述 Credit Loop 的形成条件——多交换机 + 多链路故障 + 流量同时打满
      • Why：理解 "为什么必须从路由引擎层面避免 credit loop，而不是等到故障后再去处理"——因为一旦发生，整片网络停摆，且普通运维工具（如 ibstat）看不出任何异常
  • 第 5 步 · Up/Down 路由引擎与配置（第九节、第十节、第十一节）
      • What：Up/Down 算法的核心规则——禁止从下行链路转发到上行链路，合法路径只能"上升"或"上升后下降"或"保持同层"，不能"先下降后上升"
      • How：能在 opensm.conf 中通过 routing_engine up-down 切换 Up/Down，并用 ibroute 验证 LFT 表项中没有违反规则的"先降后升"路径
      • Why：理解 "为什么 Up/Down 内置 credit loop 避免能力"——因为其"单向上升"规则从结构上保证路径无环，因此流控信用也不可能形成闭合环

★ 阅读前提 & 本篇不涉及的内容

  • 前置知识：本系列第一篇《InfiniBand 架构简介：从五层模型到子网管理》中的 Fabric vs. Subnet、SM / SMA / MAD 三角色、GUID / LID / GID 三层地址、LID 路由与定向路由；本系列第八篇《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》中的"六阶段初始化流程"、LFT 表项结构、链路层 credit-based flow control 的基本原理；本系列第九篇《SM 监控与拓扑变化：选举、故障切换、扫描与重收敛》中的 master SM 选举与 sweep 机制。本篇不重复解释这些内容
  • 信息来源：本篇所有字段名（LFT / PortInfo / SMInfo）、拓扑名称（Fat Tree / Dragonfly+ / 3D Taurus）、路由引擎名称（up-down / minhop / dor / ftree）、配置项名（routing_engine / -R）均引自文末「参考资料」列出的 include/rdma/ib_mad.h、include/rdma/ib_smi.h、OpenSM 用户手册与 IBTA 规范原文；命令输出格式引自 opensm(8) 官方 man page
  • 本篇不涉及：QP / RC / UD 等传输层细节（见第二篇）、子网初始化六阶段的内部细节（见第八篇）、SM 选举与 failover / handover（见第九篇）、QoS 策略配置语法、组播路由 MFT 表的细节、随机转发表（Random Forwarding Table）的散列细节

📑 本节目录（按"拓扑设计 → 拓扑类型 → 路由机制 → 配置验证"展开）

  1. 一、网络拓扑的定义：物理拓扑与逻辑拓扑
  2. 二、Fabric 拓扑设计的关键考量：可用性、可靠性、性能、未来扩展与预算
  3. 三、Leaf-Spine 架构：扁平、低延迟、确定跳数
  4. 四、Fat Tree 拓扑：胖树与过订阅比（1:1 非阻塞 vs. 2:1 / 3:1 阻塞）
  5. 五、Dragonfly+ 拓扑：组内全连接、组间全网格
  6. 六、3D Taurus 拓扑：三维环面与超大规模扩展
  7. 七、自适应路由（AR）：从单路径到多端口负载均衡
  8. 八、信用环（Credit Loops）：无损网络中的死锁陷阱
  9. 九、Up/Down 路由引擎：避免信用环的经典算法
  10. 十、路由引擎与拓扑的对应关系：怎么选、怎么配
  11. 十一、配置 OpenSM 运行 Up/Down 路由引擎（含验证）
  12. 十二、FAQ 高频问答（20 组）
  13. 十三、Roadmap 后续预告

一、网络拓扑的定义：物理拓扑与逻辑拓扑

What — 这一节讲清楚两件事

课程开篇明确：网络拓扑（network topology） 是 "节点与链路等元素构成的网络结构描述"——这层定义把 fabric 拓扑从"画图软件画的连线图"提升到了"用于设计与验证的形式化结构"。课程紧接着给出了两对术语，必须分开理解：

  1. 物理拓扑（physical topology）——描述网络上的设备是如何连接起来的（describes how devices on the network are connected）
  2. 逻辑拓扑（logical topology）——描述数据是如何从一个节点移动到另一个节点的（describes how data moves from one node to another）

把两句话合起来看：物理拓扑是"用线缆把交换机与 HCA 拼成什么形状"，逻辑拓扑是"包从 A 出发到 B 中间经过哪些跳、经过哪些端口"。两者在 IB fabric 里是解耦的——同一套物理拓扑（譬如同一个 fat tree）可以配出完全不同的逻辑拓扑（譬如一条 Min Hop 路径 vs. 一条 Up/Down 路径），反之亦然。这种解耦是 IB fabric 设计与一般 Ethernet 设计最大的区别：IB 的"路径"是 SM 集中算出来的，物理连线只决定可达性，路径的形态由路由算法决定。

1.1 物理拓扑：决定"能不能通"

课程指出，物理拓扑描述的是设备之间如何连接。在 IB fabric 语境下，物理拓扑回答的是"哪些 HCA 端口插在了哪些交换机端口上、哪些交换机端口之间有物理链路"——这是 fabric 是否能"被初始化"的前置条件。课程的描述用了"links and nodes"作为两个基本元素，links 指物理链路（physical link），nodes 指端点（end nodes，HCA / TCA）与转发节点（forwarding nodes，switch）。

课程没有展开物理层的具体参数（如线缆类型 / 端口速率 / 光模块波长），但这些参数属于物理拓扑的下属维度。在工程实践里，物理拓扑的可观测面是 ibnetdiscover 输出的连接图，而每个节点的物理端口速率、宽度、状态则可通过 ibstat 与 perfquery 读取。第八篇讲过，物理端口状态机有 Polling / Disabled / Configure / LinkUp / LinkErrRecovery / PhyTest 六个状态，任一物理端口停留在非 LinkUp，都意味着这条链路没被 SM 计入"可用"。

Tip · 物理拓扑与逻辑拓扑的"边界"

区分这两个概念的最简办法是问两个问题：

  • 问"物理"：拔掉这条线缆，链路两端的设备还能互相 ping 吗？——能，说明这条线缆不是物理拓扑的"必经"；不能，说明它就是必经的
  • 问"逻辑"：包从 A 到 B 走的路径换了，但所有线缆没动过——这是逻辑拓扑变了

在 IB 里，所有路径都来源于 SM 计算后下发的 LFT 表，所以"逻辑拓扑变了"几乎总是等价于"SM 重算了 LFT 表"。

1.2 逻辑拓扑：决定"怎么走"

课程对逻辑拓扑的定义是"数据如何从一个节点移动到另一个节点"。在 IB fabric 里，逻辑拓扑由两个独立维度共同决定：

  • 一是每台交换机的 LFT（Linear Forwarding Table）——对于"目的 LID → 出口端口"的映射。LFT 的每一条表项由 SM 在初始化阶段集中算出，并下发到交换机硬件，运行期基本不修改
  • 二是 SL-to-VL 映射——同一条物理路径上，传输服务（SL）如何映射到虚通道（VL）。这是 QoS 的"分车道"机制，不改变路径本身，但改变了同一条路径上不同流的隔离方式

课程没有提到 SL-to-VL，但作为"逻辑拓扑"的一部分必须理解：物理上同一条路径，在不同的 SL 上会走不同的 VL 队列，于是不同流的服务质量在"同一个物理拓扑上"也能拉开档次。这一层是本系列第八篇已经讲过的内容，本篇只在与"路由算法"耦合的层面引用，不展开。

1.3 一对容易混淆的近义词：物理拓扑 vs. 逻辑拓扑

维度物理拓扑（Physical Topology）逻辑拓扑（Logical Topology）
回答的问题 设备之间怎么连的 数据怎么走的
基本元素 links（物理链路）+ nodes（端点 + 交换机） LFT（线性转发表）+ SL-to-VL（服务等级到虚通道映射）
决定者 硬件连接——线缆 / 端口 / 光模块 SM 集中算出的路径——由 routing_engine 配置项控制
可观测工具 ibnetdiscover / ibstat / perfquery ibroute（读交换机 LFT）
故障影响 链路 down → 物理上不可达 LFT 不正确 → 物理可达但包不送达

课程把这一对术语放在第一节最前面，目的是为后续四节（fat tree / Dragonfly+ / 3D Taurus / 自适应路由）建立"看拓扑"的两层视角：先看物理上能拼出什么形状，再看 SM 在这个形状上算出了什么路径。读后续章节时，每一段都建议先问自己"这是在讲物理层还是逻辑层"——很多概念冲突其实都来自这两层的混淆。

二、Fabric 拓扑设计的关键考量：可用性、可靠性、性能、未来扩展与预算

What — 这一节讲清楚一件事

课程明确：选择网络拓扑时需要考虑的关键因素（the following are the key considerations when choosing a network topology）有五类。课程按重要程度依次列出：

  1. 可用性（availability）——运行关键应用的企业需要网络资源的最大可用性。高可用特性必须在整个网络中得到体现——硬件 / 软件网络协议、环境与供电特性都贡献到整体可用性
  2. 可靠性（reliability）——在许多行业里，即使是短暂的 downtime 和延迟也是不可接受的，因此网络可靠性是基本考量
  3. 性能（performance）——网络拓扑是决定其性能的关键。选择正确的拓扑可以提高性能，同时更容易定位故障、排查错误、更有效地在网络上分配资源
  4. 未来扩展（future growth）——如果网络预期在中长期会增长，选择一种容易添加新节点、且不影响性能与用户体验的拓扑
  5. 预算（budget）——可以选到完全满足需求的拓扑，但可能负担不起——通常有低价的备选方案几乎一样有效

课程在第一篇讲 IB 适用场景时已经说过 "HPC / AI / 云原生" 三类应用对性能和规模有独特的要求，本节把这层需求翻译成了"在 IB fabric 设计阶段，五个因素怎么权衡"——这五个因素在普通 Ethernet 设计里也是通用的，但 IB fabric 的特点是：很多权衡可以由"软件配置"完成（譬如 LFT 重算），而不需要"硬件重连"。

2.1 可用性（Availability）：链路冗余 + SM 冗余

课程对可用性的定义是"企业运行关键应用需要网络资源的最大可用性"。在 IB fabric 里，可用性通过两层冗余实现：

  • 网络设备层冗余——每台 leaf 交换机连接到所有 spine 交换机，任意一台 spine 故障，leaf 上的所有 HCA 仍可通过其它 spine 到达——这是 fat tree 的"每个 leaf 都可以到达所有 spine"特性
  • 控制平面冗余——同时存在两个 SM（一主一备），主 SM 失效后备用 SM 接替——本系列第九篇的 failover / handover 就是这一层

课程没有具体指出 IB 中可用性对应哪些配置项，但工程上常用的两个旋钮是：leaf 与 spine 之间的链路数量（增加冗余度）与 SM 优先级配置（避免 Double Failover）。两者都是本系列第九篇已经讲过、本篇要在"拓扑视角"再讲一遍的内容。

2.2 可靠性（Reliability）：IB 的"硬件级保证"

课程说"在许多行业里，即使是短暂的 downtime 和延迟也是不可接受的"。在 IB fabric 里，可靠性的最核心保证是链路层基于信用的流控（credit-based flow control）——这是 IB 协议层定义的"不丢包"机制，与 Ethernet 的"丢包由上层重传"完全不同。课程在第八节讲 credit loop 时会再次触及这个特性，本节先建立"IB 是无损网络"这个前提。

无损网络带来的好处是RDMA 可以在协议层不做任何重传——所有"包已发出"的承诺在硬件层面就被保证，CPU 完全不参与丢包检测与重传，因此 RDMA 能实现微秒级延迟与 200Gbps 线速转发。这个特性是 Ethernet 阵营在 RoCE v2 上靠 PFC（Priority Flow Control）模拟的，但 RoCE v2 在大流场景下需要精细的 ECN / QoS 配合，原生 IB 在这一点上有协议级优势。

注意 · "无损"也是"信用环"的来源

课程第八节会讲：credit-based flow control 虽然保证不丢包，但同时把"反压"这件事推到了链路层——当下游端口 buffer 满时，上游会"卡住"不发包。如果一组交换机的 buffer 形成闭合环，整环最终会死锁。这是 IB fabric 设计里需要从路由算法层面主动规避的一类现象，不是靠"加大缓存"就能解决。

2.3 性能（Performance）：跳数确定 + 带宽聚合

课程说"网络拓扑是决定其性能的关键"。在 IB fabric 里，性能由两个独立维度共同决定：

  • 跳数（hop count）——课程里反复出现"leaf-spine-leaf 或 3 跳"这样的描述。跳数越小，端到端延迟越低——这条规则在每一种 IB 拓扑里都成立。fat tree 三跳、Dragonfly+ 最优两跳、3D Taurus 沿三轴环面最多三维跳数
  • 聚合带宽（aggregated bandwidth）——同一时刻可并行通过 fabric 的总带宽。这与"过订阅比（over-subscription ratio）"强相关——第四节会专门讲

课程没有提到"跳数 vs. 带宽"在工程上如何取舍，但 IB 的传统设计理念是先满足跳数确定，再谈带宽——因为 HPC / AI 应用的很多通信模式（如 all-reduce）对延迟的敏感度高于带宽。这也是为什么 fat tree / Dragonfly+ / 3D Taurus 三种主流 IB 拓扑都优先保证跳数确定。

2.4 未来扩展（Future Growth）：fabric "可加节点" 的成本

课程说"如果网络预期在中长期会增长，选择一种容易添加新节点、且不影响性能与用户体验的拓扑"。这条考量在 IB fabric 里特别关键，因为 IB fabric 几乎是一旦部署就跑很多年的基础设施——HPC 集群、超算、AI 训练集群都不轻易换网络。课程没有列具体数字，但不同拓扑的扩展代价差异巨大：

  • Fat Tree——扩展一个 leaf——意味着要给它新接入的每台 HCA 在所有 spine 上分配端口，几乎总是需要重新布线和重新计算 LFT。这是 fat tree 最贵的扩展
  • Dragonfly+——扩展一个 group 内节点是廉价的；扩展 group 数量需要新拉长距离线缆，但比 fat tree 全量重连便宜
  • 3D Taurus——扩展一个节点——只需在新位置插入一台交换机并连接两个邻居——几乎不需要预占端口，是扩展最廉价的一种

课程明确提到 "Dragonfly+ allows extending the fabric without the need to reserve ports compared to a fat tree topology where expanding the fabric almost always requires a significant amount of re-cabling"——这一句直接给出了 fat tree 与 Dragonfly+ 在扩展成本上的对比。反过来，3D Taurus 则是"再加一台交换机 + 两条线"的极简扩展。

2.5 预算（Budget）：非阻塞 vs. 阻塞 的代价

课程最后给出预算考量：可以选到完全满足需求的拓扑，但可能负担不起。在 IB fabric 里，预算与过订阅比（over-subscription ratio）直接绑定——同样一台 leaf 交换机，连 4 个 spine 还是连 2 个 spine，成本差一倍。课程在第四节会展开：

  • 非阻塞 fabric（1:1）——每一层的聚合带宽相等——成本最高、性能最高
  • 轻度阻塞 fabric（2:1 / 3:2）——下联带宽是上联带宽的 2 倍——成本中等、性能中等
  • 重度阻塞 fabric（3:1）——下联带宽是上联带宽的 3 倍——成本最低、突发流量下拥塞概率高

课程明确指出 "in many cases the cost makes the over-subscription acceptable"——意思就是"预算常常决定了你最后选 1:1 还是 2:1"。但要注意：阻塞 fabric 的延迟与 1:1 几乎相同——课程原话 "when a fabric is oversubscribed, the end nodes do not achieve the full bandwidth of the fabric, but the low latency is maintained"——这是 IB 与 Ethernet 的另一个区别：阻塞只影响吞吐，不显著影响延迟。

本节要点 · 五个考量 × 两个关键洞察

  • 5 个考量：可用性（availability） / 可靠性（reliability） / 性能（performance） / 未来扩展（future growth） / 预算（budget）——按课程列出的顺序
  • 洞察 1：IB fabric 的"高可用"通过网络设备层冗余 + 控制平面冗余两层实现，前者靠 fat tree 的"每 leaf 接所有 spine"特性，后者靠 master/standby SM
  • 洞察 2：IB fabric 的"未来扩展"代价按 fat tree > Dragonfly+ > 3D Taurus 递减——3D Taurus 是扩展成本最低的 IB 主流拓扑
  • 洞察 3：阻塞 fabric 的延迟与 1:1 几乎相同——这是 IB 在设计 2:1 / 3:1 fabric 时仍能保持低延迟的根本原因

三、Leaf-Spine 架构：扁平、低延迟、确定跳数

What — 这一节讲清楚一件事

课程明确：在一般情况下，InfiniBand fabric 拓扑遵循 leaf-spine 拓扑（in general, InfiniBand fabrics topologies followed the leaf-spine topology）。课程接着给出 leaf-spine 架构的形式化定义：

  1. Leaf-spine 是一种多层拓扑，由 leaf 层与 spine 层组成（a multi-layer topology composed of a leaf layer and a spine layer）
  2. Leaf 或 edge 交换机通过外部链路连接主机与节点（leaf or edge switches are connected to the hosts and nodes through external links）
  3. Spine 或 core 交换机通过内部链路互连 leaf 或 edge 交换机（spine or core switches interconnect the leaf or edge switches through internal links）

三层以上的拓展是可选的：如果网络达到一定规模，应考虑第三层交换机——最上层称为 super spine 或 core，用于互连 spine 交换机。这一层是 fat tree 在超大规模场景下的"延伸"（fat tree 第四节会展开）。2 层 = 普通 fat tree / 3 层 = 三层 fat tree，但本质都是 leaf-spine 家族的变形。

3.1 跳数确定：永远是 leaf-spine-leaf 三跳

课程在介绍 leaf-spine 优点时给出关键论据：流量在网络上永远经过相同数量的跳数，与源和目的无关（traffic always goes through the same number of hops on the network, regardless of the source and destination）。这条规则由 leaf-spine 的"无环"结构保证：

  • 同 leaf 内：host A → leaf 1 → host D——1 跳
  • 跨 leaf：host A → leaf 1 → spine 1 → leaf 2 → host D——3 跳
  • 三层 fat tree：host A → leaf 1 → spine 1 → core → spine 2 → leaf 2 → host D——5 跳

课程原话 "for example the path from host A to host D is leaf-spine-leaf or three hops"——这就是 IB fabric 上"延迟可预测"的根因：同种目的之间跳数恒定。在 Ethernet 数据中心里，Spanning Tree / ECMP / VXLAN 等技术都会让"同种目的之间跳数不固定"，这是 IB 在延迟可预测性上的根本优势。

3.2 横向扩展：所有 leaf 互不依赖

课程说 "leaf-spine 拓扑天然可扩展——任何两点之间提供大量路径"（leaf-spine topologies are also inherently scalable, providing so many paths between any two network points）。这条特性在两个层面体现：

  • 物理层：每台 leaf 都可以独立地扩展新 HCA——不需要动其他 leaf
  • 逻辑层：同 leaf 间的所有路径走同一组 spine——同 leaf 之间的路径互相独立，不会因为一台 leaf 故障影响其他 leaf

课程明确 "reduces the possibility of congestion even in a large network"——即大量路径分散了拥塞的概率。这也是为什么 leaf-spine 在大规模 fabric 上是默认选择。

3.3 冗余：每台 leaf 都可以走任意一台 spine

课程说 "每台 leaf 交换机可以连接到所有其他 spine 交换机，提供了更高级别的冗余"（each leaf switch may connect to all other spine switches providing a superior level of redundancy）。把这条规则量化：

拓扑形态每 leaf 的 spine 链路数任意 1 台 spine 故障任意 2 台 spine 故障
k=2 简单 leaf-spine 2 1/2 spine 不可达，fabric 仍工作 全部 spine 不可达，fabric 瘫
k=4 fat tree（标准） 4 3/4 spine 可达 2/4 spine 可达，fabric 仍工作
k=8 大型 fat tree 8 7/8 spine 可达 6/8 spine 可达

课程原话 "increasing bandwidth and avoiding traffic bottlenecks"——更多 spine 链路 = 更高带宽聚合 + 更高冗余。课程并没有具体给出 k 的推荐值，但工程上常见 k=4 到 k=8，取决于 leaf 交换机的端口数与单端口速率。

3.4 三层拓展：super spine 或 core 层

课程说 "如果网络达到一定规模，应考虑第三层交换机。最上层称为 super spine 或 core，用于互连 spine 交换机"。这是 leaf-spine 在超大规模场景下的延伸，三层结构的路径长度：

  • 2 层 fat tree：host A → leaf → spine → leaf → host D——3 跳
  • 3 层 fat tree：host A → leaf → spine → core → spine → leaf → host D——5 跳

课程原话 "these super spine switches can be used to connect multiple spine leaf nodes and extend the network structure beyond current capacity"——三层 fat tree 的本质是"用更多层的间接换来可扩展性"。课程没有具体说"什么规模需要三层"，但工程经验是 leaf 超过 100 台之后考虑三层，此时两层 fat tree 的 spine 端口数不够用了。

2 层 Leaf-Spine 拓扑示意：4 leaf + 2 spine = 8 host
+----------------------------+----------------------------+
|        Spine 1             |        Spine 2             |
+----------------------------+----------------------------+
   |        |       |       |   |        |       |       |
   v        v       v       v   v        v       v       v
+------+ +------+ +------+ +------+ +------+ +------+ +------+
|Leaf 1| |Leaf 2| |Leaf 3| |Leaf 4| |Leaf 5| |Leaf 6| |Leaf 7|
+------+ +------+ +------+ +------+ +------+ +------+ +------+
   |        |       |       |       |        |       |       |
   v        v       v       v       v        v       v       v
 host1    host2   host3   host4   host5   host6   host7   host8
说明：host1 (Leaf 1) -> host5 (Leaf 5) 路径 = leaf1 -> spine1 -> leaf5（共 3 跳）
     host1 (Leaf 1) -> host2 (Leaf 2) 路径 = leaf1 -> spine1 -> leaf2（共 3 跳）

注意：同 leaf 内通信（如 host1 到 host2 的某台同 leaf 邻居）只需 1 跳——不经过 spine，但多数 IB HCA 在初始化时仍会经由 SM 配置的 LFT 路径走，对单跳路径的优化由交换机的 LFT 自行判断，本篇不展开。

本节要点 · Leaf-Spine 的四个关键属性

  • 属性 1：跳数确定——跨 leaf 永远是 3 跳（同 leaf 1 跳 / 三层 5 跳），这是 IB fabric 延迟可预测的物理基础
  • 属性 2：横向扩展——每台 leaf 独立扩展 HCA，不影响其它 leaf
  • 属性 3：高冗余——每台 leaf 接到所有 spine，任意 1 台 spine 故障 fabric 仍工作（k≥2 前提下）
  • 属性 4：三层可拓展——超过 100 台 leaf 时考虑 super spine / core 层，跳数从 3 跳变 5 跳

四、Fat Tree 拓扑：胖树与过订阅比（1:1 非阻塞 vs. 2:1 / 3:1 阻塞）

What — 这一节讲清楚两件事

课程明确：fat tree 背后的基本思想是通过附加链路来缓解靠近根节点的带宽瓶颈（the basic idea behind fat trees is to alleviate the bandwidth bottleneck closer to the root with additional links）。课程接着给出 fat tree 的形式化定义：

  1. Fat tree 拓扑是类树拓扑，其中靠近层次顶部的链路更"胖"——也就是说，它们比层次较低的链路有更多的带宽（a fat tree topology is a tree-like topology where links closer to the top of the hierarchy are fatter, that is, they have more bandwidth than links further down the hierarchy）
  2. Fat tree 拓扑已被证明可以提供高效通信——可调整的"厚度"或带宽能够支持大多数高性能网络

把两句话合起来看："fat tree" 这个名字里的"fat"指的不是"线缆更粗"，而是"靠近根的链路带宽更高"——在 IB 语境下，这等价于每台 leaf 交换机连到所有 spine 交换机，每条 spine 链路的聚合带宽与 leaf 下联带宽相等或更高。这也直接引出了 "过订阅比（over-subscription ratio）" 这个核心概念。

4.1 过订阅比：下联带宽 / 上联带宽

课程明确：过订阅比（over-subscription ratio） 定义为 下联带宽（down links，连接主机到 leaf 交换机）与上联带宽（up links，连接 leaf 交换机到 spine）的比值。课程原话 "the over-subscription ratio is typically defined as the ratio of bandwidth for down links, links connecting hosts to leaf switches, to the bandwidth for up links, links connecting leaf switches to spines"。

注意课程的措辞："下联 / 上联"而不是"上联 / 下联"——在工程上"比值大于 1"表示下联带宽比上联带宽更高，这是过订阅的标志。比例 1:1 表示上下联相等，是非阻塞 fabric 的标志。课程给出了一个 1:1 的具体例子：

1:1 非阻塞 fat tree 示例（每条链路带宽均为 n）：
  4 台 leaf 交换机，每台 leaf 有 4 条下联到服务器 -> 16 条下联链路 = 16n
  4 台 leaf 交换机，每台 leaf 有 4 条上联到 spine  -> 16 条上联链路 = 16n
  过订阅比 = 16n / 16n = 1:1  ->  非阻塞 fabric
  spine 交换机数 = 4（每台 spine 接收 4 条上联）

课程给出了一个 2:1 的具体例子：

2:1 阻塞 fat tree 示例（每条链路带宽均为 n）：
  4 台 leaf 交换机，每台 leaf 有 24 条下联到服务器 -> 96 条下联链路 = 96n
  4 台 leaf 交换机，每台 leaf 有 12 条上联到 spine -> 48 条上联链路 = 48n
  过订阅比 = 96n / 48n = 2:1  ->  阻塞 fabric
  含义：端节点能用的总带宽是 fabric 上联带宽的 2 倍 -> 突发流量下 50% 概率拥塞

4.2 非阻塞 vs. 阻塞 fabric：成本与性能的权衡

课程对非阻塞 fabric 的定义是 "在 fabric 架构中，层次结构的每一级都以相等或更高的聚合带宽连接到下一级"（in a non-blocking fabric architecture, every level of the hierarchy is connected to the next level with equal or higher aggregate bandwidth）。课程紧接着明确：非阻塞 fat tree 提供更多性能，但成本更高（nonblocking fat tree yields more performance, but this comes at a cost）——因此实际的 fat tree fabric 经常是过订阅的（therefore real fat tree fabrics are very often oversubscribed）。

对阻塞 fabric，课程的定义是 "不同 fat tree 级别的带宽不相等——也就是说，进入层次结构某一级的带宽大于通向下一级的聚合带宽"（in a blocking architecture, the bandwidth at different fat tree levels is not equal, that is, the bandwidth entering one level of the hierarchy is greater than the aggregate bandwidth going to the next level）。课程给出的具体比值是 2:1 / 3:1 / 3:2 三种，具体选哪种取决于 fabric 的规模。

Tip · 阻塞 fabric 的"延迟 vs. 带宽"分离特性

课程原话 "when a fabric is over-subscribed, the end nodes do not achieve the full bandwidth of the fabric, but the low latency is maintained"——翻译过来是：阻塞 fabric 的延迟与 1:1 几乎相同，但带宽打不到 fabric 理论值。这是 IB 与 Ethernet 阻塞 fabric 的本质区别：

  • Ethernet 阻塞 fabric：拥塞直接导致排队延迟——延迟与带宽同受影响
  • IB 阻塞 fabric：拥塞由 credit-based flow control 在链路层反压——包被"挡住"不丢，但延迟会随拥塞上升而变高，但延迟仍然保持"低"

工程含义：对延迟敏感的应用（all-reduce / 集合通信）选 2:1 阻塞 fabric 仍然可接受，但对带宽敏感的应用（如大规模流式读写）应选 1:1 非阻塞。

4.3 跳数与延迟：fat tree 的可预测性

课程说 "fat tree 拓扑也提供对穿越 fabric 的 packet 的最低且确定性延迟"（fat tree topologies also provide lowest and deterministic latency for packets traversing the fabric）。具体的跳数：

  • 2 层 fat tree：包路径为 leaf-spine-leaf——最多 3 跳
  • 3 层 fat tree：包路径为 leaf-spine-core-spine-leaf——最多 5 跳

跳数恒定的好处是延迟可预测——在 SLA 严格的金融 / HPC 场景下，3 跳 vs. 5 跳的差异是"5 跳延迟 ≈ 3 跳 + 2 个 spine 转发延迟"，可以预先建模到应用的延迟预算里。

4.4 fat tree 的优势小结

课程在最后用一段列出了 fat tree 的 4 个核心优势——这 4 个优势几乎是 fat tree 之所以成为 HPC / AI 训练 fabric 默认选项的全部理由：

  1. 高效通信：fat tree 拓扑通常能为大多数高性能网络提供高效通信
  2. 非阻塞可选：fat tree 拓扑可以设计为提供非阻塞带宽——但成本高
  3. 过订阅可调：为了更经济且可扩展的方案，可以调整过订阅比
  4. 延迟确定：fat tree 拓扑对穿越 fabric 的 packet 提供最低且确定性的延迟

课程原话 "fat tree topologies also provide lowest and deterministic latency for packets traversing the fabric. in a two level fat tree topology packets follow the path leaf-spine-leaf or three hops at most. and in a three level fat tree topology, the path is leaf-spine-core-spine-leaf or five hops at most"——把这一段与 3.3 节对比，本质上 3 层 fat tree 就是 "3 层 leaf-spine"，两者的描述完全一致。课程在第 3 节讲 leaf-spine 时给的是 3 跳，在第 4 节讲 fat tree 时给的是 2 层 3 跳 / 3 层 5 跳——二者是同一个家族。

"胖"的真正含义：fat tree 不是"线更粗"，而是"带宽更宽"

课程里 fat tree 的 "fat" 一词容易被误读成"线缆物理更粗"。实际上，在 IB 语境下 "fat" 指的并不是线径或物理形态，而是链路数量与聚合带宽。这一节把 1:1 与 2:1 算出来之后，"fat" 的工程含义就很清晰了：

  • 1:1 非阻塞 fat tree：每台 leaf 的 24 个下联端口 + 24 个上联端口——上联聚合 = 下联聚合。"胖"在上联
  • 2:1 阻塞 fat tree：每台 leaf 的 24 个下联端口 + 12 个上联端口——上联聚合 = 下联聚合的 1/2。"胖"在下联，上联相对"瘦"

把 "fat" 与 "tree" 拆开看：

词字面含义在 IB 里的工程含义来源
fat 胖、宽 靠近根的链路聚合带宽≥下级聚合带宽 课程原话 "links closer to the top of the hierarchy are fatter... more bandwidth than links further down"
tree 树 无环的层次结构——从 root 到 leaf 唯一路径 课程原话 "a tree-like topology"

从协议规范层面看，fat tree 的 "fat" 完全不是物理形态。它与原始电话交换树（binary tree）不同：原始 tree 在 root 处的链路带宽恒定，越靠近 root 越成为瓶颈；fat tree 在 root 处的链路带宽被刻意加大，瓶颈从 root 转移到 leaf。这一设计改动的代价是端口数（每台交换机需要更多高速端口），收益是聚合带宽。在 IB 场景下，每台 leaf 交换机配 32 / 64 端口，因此 1:1 fat tree 在 64 leaf 的 fabric 上需要 64 台 spine——这也是 fat tree 的扩展上限：spine 端口数成为限制，超过这个上限就要进入 3 层 fat tree 或 Dragonfly+。

五、Dragonfly+ 拓扑：组内全连接、组间全网格

What — 这一节讲清楚四件事

课程明确：Dragonfly+ 拓扑被提出作为另一种方案——在减少长电缆数量与成本的同时，对各种流量模式表现良好（Dragonfly+ topology was introduced as an alternative to show good performance of various traffic patterns while reducing the cost and number of long cables compared to other topologies）。课程的描述可拆为四层：

  1. Dragonfly+ 是把成组计算节点以全网格（all-to-all）拓扑互连的概念，其中每个组至少有一条到另一组的直连链路（a concept of connecting groups of compute nodes in a full mesh all-to-all topology where each group has at least one direct link to another group）
  2. 组内的网络节点以全二部图（full bipartite topology）拓扑连接——只允许 leaf-spine 连接（the network nodes inside the group are connected in a full bipartite topology that is only leaf-spine connections are allowed）
  3. 组间以全网格（full mesh）拓扑连接——每个组都直接连接到所有其他组（the groups are interconnected in a full mesh topology where each group is connected directly to all other groups）
  4. Dragonfly+ 需要一种自适应路由（adaptive routing）算法来在路由 packet 时实现高效运行——这一点会在第七节展开

把四层合起来看：Dragonfly+ 是一种"组内 leaf-spine、组间全网格"的二维层次拓扑。它的核心创新在于把"长距离组间链路"的数量压到了全网格的最少。这是 fat tree 在超大规模场景下成本过高的"经济替代方案"。

5.1 跳数：组内 1 跳 / 组间 2 跳

Dragonfly+ 的路径有两种：

  • 组内通信：host A → 同组 leaf → host B——1 跳（如果同 leaf）或 3 跳（如果跨 leaf）
  • 组间通信：host A → 源组 leaf → 源组 spine → 目的组 spine → 目的组 leaf → host B——5 跳（必经组内 leaf-spine）

但课程原话 "Dragonfly+ requires an adaptive routing algorithm to enable efficient operation when routing packets"——这是 Dragonfly+ 区别于 fat tree 的关键：组间通信有多条等代价路径，必须靠 AR 选择最优。

5.2 可扩展性：超大主机数 + 不预占端口

课程原话 "Dragonfly+ supports a large number of hosts, it allows extending the fabric without the need to reserve ports compared to a fat tree topology where expanding the fabric almost always requires a significant amount of re-cabling"——把这一句拆成两层：

  • 支持大量主机：因为每个组内 leaf-spine 是完整的，再加组间全网格——组数可以很大
  • 不需要预占端口：组内新加节点只需新拉两条线——fat tree 必须在所有 spine 上预留端口

课程明确 "Dragonfly+ also provides low latency communication and high bandwidth, resulting in a flexible growth of the system and cost reduction"——这与第 2.4 节"未来扩展"的判断完全一致：Dragonfly+ 的扩展成本远低于 fat tree。

5.3 Dragonfly+ 的代价：必须配 AR

课程明确 "Dragonfly+ requires an adaptive routing algorithm to enable efficient operation when routing packets"——这一条是 Dragonfly+ 的"必要配置"，不是可选项。理由是：

  • 组间有多条等价路径——每对组之间至少有 1 条直连链路（课程原话 "each group has at least one direct link to another group"）——在大量组时实际有几十条等价路径
  • 流量分布不均——AI / HPC 流量有热点——如果只选一条路径，则其它空闲路径浪费、热点路径拥塞
  • AR 才能动态选择最不拥塞的端口——这与第七节会讲的 AR 机制直接对应

注意 · Dragonfly+ 在 OpenSM 里的对应配置

Dragonfly+ 在 OpenSM 中是作为拓扑结构描述的——SM 在初始化阶段会通过 SMP 包发现组内 leaf-spine、组间全网格的结构。路由引擎方面，OpenSM 通过 routing_engine 切换到与 Dragonfly+ 兼容的算法——这是第十节会展开的内容。本节只需要记住：Dragonfly+ 与 AR 是绑定的，没有 AR 的 Dragonfly+ 几乎不能跑大规模 AI 训练。

本节要点 · Dragonfly+ 的 4 个关键特性

  • 特性 1：组内 leaf-spine + 组间全网格——二维层次结构
  • 特性 2：组间 5 跳（必经组内 leaf-spine）——比 fat tree 的 3 跳多 2 跳
  • 特性 3：支持超大主机数 + 不预占端口——扩展成本远低于 fat tree
  • 特性 4：必须配 AR——否则流量分布不均会导致热点拥塞

六、3D Taurus 拓扑：三维环面与超大规模扩展

What — 这一节讲清楚两件事

课程明确：3D Taurus 拓扑中，节点以三维 x / y / z 环形（ring）连接（in a 3D Taurus topology, nodes are connected in a ring formation in three dimensions x, y, and z）。课程接着给出形式化定义：

  1. 每个节点向每个环提供 2 条链路——即每节点 6 条链路——即每个节点连接到 6 个邻居（each node provides two links to each ring or six links per node, that is, every node is connected to six neighbors）
  2. 在 Taurus 中加入更多维度的主要动机是在连接大量节点时保持低延迟（the main motivation for more dimensions in a Taurus is to maintain low latency when connecting a large number of nodes）
  3. 3D Taurus 拓扑非常可扩展且有弹性——如果一个环断裂，仍有多条路径通过剩余的运行环到达数据的目的地——新路径可能会增加一些延迟（3D Taurus topology is very scalable and resilient if a ring breaks there are multiple paths to get the data to its destination through the remaining operational rings. the new path might add some latency）

把三层合起来看：3D Taurus 的核心创新是"在三维空间内做环面（torus）"——每台节点都同时参与 x / y / z 三个独立环，任意两节点之间最多沿三轴各走一段。这与 fat tree 的"层次汇聚"和 Dragonfly+ 的"组内层次 + 组间全网格"都不同——3D Taurus 是对等拓扑。

6.1 拓扑结构：每节点 6 个邻居

课程原话 "each node provides two links to each ring or six links per node that is every node is connected to six neighbors"——把这一句翻译成图：

3D Taurus 节点连接图（每节点 6 个邻居）：

       [z-]  <-+                +->  [z+]
                \              /
                 +--[Node X]--+
                /              \
       [y-]  <-+                +->  [y+]

       [x-]  <-+                +->  [x+]

说明：
  - x- / x+  : 沿 x 轴正负方向各一条链路
  - y- / y+  : 沿 y 轴正负方向各一条链路
  - z- / z+  : 沿 z 轴正负方向各一条链路
  - 每节点总 6 条链路，3 对相反方向
  - 每个维度形成独立的 ring

课程给出了一个具体例子：一台 36 端口的交换机——其中 18 个端口连接 18 台服务器，另外 18 个端口（6 个邻居各 3 条链路）连接到 6 个相邻交换机。课程原话 "in this example of a 3D Taurus topology we depict a switch connected with 36 ports. each switch is connected to 18 servers via 18 ports. the remaining 18 switch ports are connected to 6 neighboring switches, three links to each neighbor represented by the axes x, y, and z"。注意课程里"每个邻居 3 条链路"是与"每节点 6 个邻居"对应的：

维度邻居数每邻居链路数总链路数
x 轴 2（x+ / x-） 3 6
y 轴 2（y+ / y-） 3 6
z 轴 2（z+ / z-） 3 6
合计 6 个邻居 3 / 邻居 18 上联 + 18 下联 = 36

课程明确 "the over-subscription ratio in this example is 6:1"——在这个具体例子里，18 个下联（每服务器 1 链路）vs. 18 个上联（每邻居 3 链路）——但这是把 3 维 x/y/z 各 1 链路都算上联时的比值。实际工程上 3D Taurus 的"阻塞 vs. 非阻塞"更复杂，这与 fat tree 的过订阅比定义不同——本节不展开。

6.2 容错：环断裂时切换到其它维度

课程明确 "3D Taurus 拓扑非常可扩展且有弹性——如果一个环断裂，仍有多条路径通过剩余的运行环到达数据的目的地——新路径可能会增加一些延迟"——把这一句翻译成可观测的行为：

  • x 轴环断裂：包从 y 轴或 z 轴绕行——可能增加 1~2 跳
  • 多维环同时断裂：极端情况下包路径变成"穿越整个 fabric 的大对角线"——延迟大幅上升但仍可达
  • 节点故障：3D Taurus 的邻居替换规则让单节点故障只影响直接邻居的 2 跳路径——故障域被严格隔离

课程最后明确 "finally, 3D Taurus is also fault tolerant with the ability to handle multiple switch and link failures"——3D Taurus 在大规模 fabric 上的容错能力是它的"招牌特性"。

6.3 适用场景：超大规模 + 数据密集

课程给出 3D Taurus 的两类典型场景：

  1. 局部性计算节点之间的通信——课程原话 "3D Taurus is best used for applications that use communications between localized compute nodes as this locality is usually required to achieve optimal performance and low latency"。这把 3D Taurus 与 fat tree 区分开：fat tree 适合"任意两点通信"，3D Taurus 适合"局部通信"
  2. 超大规模 + 数据密集型应用——课程原话 "one of its main benefits is its low cost, which makes 3D Taurus ideal for very large installations such as supercomputers with thousands of nodes. running data intensive applications spanning a wide variety of domains such as genomics, graph problems, geophysics and data mining"——基因组学 / 图问题 / 地球物理 / 数据挖掘四类应用都有"局部性"特征

课程最后列举的成本/工程优势：

  • 布线简单：电缆更短——只需在新位置插入一台交换机并连接到两个邻居
  • 成本/能效：成本有效、节能、有弹性的设计
  • 超大规模：适合超大规模部署——如带数千节点的超级计算机

设计视角 · 三种拓扑的"设计取向"对比

把 fat tree / Dragonfly+ / 3D Taurus 放在一起对比，可以看出三种拓扑的设计取向完全不同：

  • Fat tree：设计取向是"层次汇聚 + 任意两点等代价"——用"多 spine + 多链路"换"任意通信性能一致"
  • Dragonfly+：设计取向是"组内层次 + 组间对等"——用"组内自洽 + 组间多条路径"换"超大规模 + AR 灵活性"
  • 3D Taurus：设计取向是"三维环面 + 局部性优先"——用"每节点 6 邻居 + 局部最优"换"超大规模 + 容错 + 局部应用"

这三种设计取向共同构成了 IB fabric 在"性能 / 规模 / 成本"三角上的全部可能性。没有"绝对最好"的拓扑——只有"对当前应用最合适"的拓扑。

本节要点 · 3D Taurus 的 4 个关键特性

  • 特性 1：每节点 6 邻居——三维 x/y/z 各 2 个相反方向邻居
  • 特性 2：环断裂时切换到其它维度——延迟上升但仍可达
  • 特性 3：适合局部性应用——基因 / 图 / 地球物理 / 数据挖掘
  • 特性 4：扩展成本最低——再加一台交换机 + 两条线——是超大规模 IB fabric 的首选

七、自适应路由（AR）：从单路径到多端口负载均衡

What — 这一节讲清楚两件事

课程明确：本节介绍一种叫做"自适应路由"的路由特性——它能在 InfiniBand fabric 上实现流量负载均衡。紧接着给出 AR 的核心机制：

  1. 如本系列第八篇子网初始化所述，SM 为每台交换机计算到达子网节点的路径（as discussed in unit eight fabric initialization, the subnet manager calculates routes for each of the switches to reach the nodes in the subnet）
  2. 大多数路由算法以最小跳数作为最佳路由选择的基础判据（most of the routing algorithms use a minimum of hops as the base criteria for the best route selection）
  3. 由路由算法确定的最佳路由被放入交换机的转发表中——标识所选择的出口端口——这是从交换机发送到该目的 LID 的唯一端口（the best route determined by the routing algorithm is placed in the switches forwarding table identifying the selected exit port. this is the only port used to send traffic from the switch to that destination lid）
  4. 如果存在到给定目的 LID 的多条最小跳数路径，会发生什么？（now, what if there are multiple paths to a given destination lid with the minimum hop count?）——在这种情况下，只有一条路由被选为最佳路由并被安装到交换机的转发表中（also in this case only one route is chosen as the best route and is installed in the switches forwarding table）

把四点合起来看，这是"确定性路由"的工作模式：SM 选一条最优路径写进 LFT，包到达交换机后只看 LFT 选出口——不感知拥塞、不感知流量。AR 是对这种模式的结构性增强。

7.1 问题的提出：单路径可能在热点拥塞

课程给出一个具体例子：交换机 E 有两条到目的 LID 8 的路径——每条 2 跳——一条经过端口 1、另一条经过端口 2（looking at this example, we can see that the switch E has two paths to destination lid 8 with two hops for each path. one path is via port 1 and the other via port 2）。课程接着描述：

  • 如果 SM 选择经过端口 2 的路径——该路径连接到 spine 交换机 B——那么经过 spine 交换机 A 的另一条路径将完全不被使用（let's assume that the subnet manager chooses the path via port 2 that connect switch E to spine switch B. the other path via spine switch A is not used at all）
  • 如果有大量流量从交换机 E 到 LID 8——这条单一路径可能会过订阅（if there is massive traffic going from switch E to LID 8, that single path may become over-subscribed）

这就是"确定性路由的代价"：SM 算出的最优路径在被写入 LFT 后就是固定的——运行期不感知拥塞。在热点流量场景下，一条"最优"路径可能成为整个 fabric 的瓶颈。

7.2 解决思路：负载均衡到多条等价路径

课程给出解决方案：更好的路由策略是利用所有可用路径并对流量进行负载均衡（a better routing strategy would be to utilize both available paths and load balance the traffic）。课程给出负载均衡的形式化定义：

  • 负载均衡是一种路由策略——其中被转发到单个目的的流量可以发生在多条路径上（load balancing is a routing strategy in which traffic that is forwarded to a single destination can occur over multiple paths）
  • 在我们例子中的含义是：如果有两条可用路径且具有相同最小跳数到一个目的 LID——这两条路径都可以用于流量转发——这将允许对流量进行负载均衡——从而提供两倍的带宽和更好的资源利用率（that will allow for load balancing the traffic hence providing twice the bandwidth and better resource utilization）

课程对 "twice the bandwidth" 的措辞需要谨慎理解：在 2 路径的场景下，流量被均分到两条路径——总聚合带宽确实是 1 路径的 2 倍。但这并不是无限制的——它受限于"等跳数路径"的实际数量。

7.3 AR 的工作机制：端口组 + 动态选端口

课程给出 AR 的工作方式：

  1. 启用 AR（通常缩写为 AR）后——路由算法识别具有到目的 LID 相同代价（最小跳数）的一组端口——并将其安装到交换机转发表中（with adaptive routing commonly referred to by the acronym AR enabled, the routing algorithm identifies a group of ports having the same cost towards a destination lid. minimum hop count and installs them in the switch forwarding table）
  2. 对于每个连接，交换机动态选择最不拥塞的端口——如果某个端口失败或经历拥塞——包将被重新路由到组中的另一个端口（for every connection the switch dynamically chooses the least congested port. if a port fails or experiences congestion, packets are rerouted to another port in the group）

把这两点合起来：AR 在 LFT 层把"单端口表项"扩展为"端口组表项"——在每条流/包级别动态选端口。这是与确定性路由"端口一旦选定，运行期不再变化"的本质区别。

Tip · AR 与 SL-to-VL 的"分工"

AR 与 SL-to-VL 都是 IB fabric 上"流量调度"的手段——但分工不同：

  • AR：在路径选择层面——同一目的 LID 在多个端口之间动态选
  • SL-to-VL：在虚通道分配层面——同一条路径上不同 SL 走不同 VL

两者可以叠加使用：AR 选路径——路径上的 SL-to-VL 决定这条流在每跳的虚通道。AR 解决"路径层负载均衡"问题，SL-to-VL 解决"同路径内 QoS 隔离"问题。

7.4 AR vs. 确定性 vs. 遗忘式：流量模式下的对比

课程明确 "AR 减少争用并为许多非均匀流量场景提供优于确定性和遗忘式路由的性能"（AR reduces contention and offers superior performance compared to deterministic and oblivious routing for many non-uniform traffic scenarios）。这一句把三种路由策略的对比说清楚了：

策略路径选择时机是否感知拥塞适用流量模式
确定性路由（Deterministic） SM 在初始化阶段静态决定 不感知 均匀流量、热点少
遗忘式路由（Oblivious） 每包随机选路径 不感知拥塞，但每包独立选 流量分布广且无热点
自适应路由（AR） 每流/每包感知拥塞后选 感知 非均匀、有热点流量

课程强调 "later we'll see that some routing engines support adaptive routing while others don't"——AR 不是默认开启的——必须显式启用。本系列第八篇讲过的 Min Hop 与 Up/Down 默认都不开 AR；Dragonfly+ / 3D Taurus 的路由引擎则通常与 AR 配套。

AR 的"端口组"概念：从 LFT 表项到端口集合

AR 的工作机制在协议层对应到LFT 表项的扩展。本系列第八篇讲过，确定性路由下 LFT 表项是 LID → 单端口的映射；AR 下 LFT 表项是 LID → 端口组的映射。这一变化对应到 IBTA 规范的几个字段：

  • PortInfo（属性 0x0015）中的 PortState 字段：标识端口是 AR-enabled（0x02）还是 AR-disabled（0x01）——这一字段控制端口是否参与 AR 的端口组选择
  • LinearForwardingTable（属性 0x0019）：每条表项仍是一条 LID → 端口的映射——但 AR 模式下 SM 可以为同一 LID 写入多条表项——交换机会把它们视为一个"端口组"
  • RandomForwardingTable（属性 0x001A）：AR 的另一可选实现——通过散列方式选端口——通常与 AR 配合使用

从协议层看，AR 的"端口组"不是协议的新结构——而是 SM 在初始化时把多条 LFT 表项"叠加"在同一个 LID 上，交换机内部硬件按"拥塞感知"在它们之间动态选。这一设计的精妙之处在于：协议层没有引入新的"组表"数据结构——扩展性完全由 SM 的算法决定。

本节要点 · AR 的 4 个核心机制

  • 机制 1：端口组替代单端口——LFT 表项从"单 LID → 单端口"扩展到"单 LID → 端口组"
  • 机制 2：动态选端口——每流/每包感知拥塞——选最不拥塞的端口
  • 机制 3：故障时自动切换——端口失败或严重拥塞时——包被路由到组内其它端口
  • 机制 4：必须显式启用——Min Hop / Up/Down 默认关闭——AR 是可选的路由策略

八、信用环（Credit Loops）：无损网络中的死锁陷阱

What — 这一节讲清楚两件事

课程明确：本节介绍一种叫做"credit loops"的现象——如果它发生在 fabric 中可能会造成死锁——因此必须避免。课程紧接着给出 credit loop 的根因：

  1. 如本系列第四篇所述，InfiniBand 中的链路层使用基于信用的流控机制——以避免在拥塞存在时丢包（as we saw in unit four, the link layer in InfiniBand uses a credit based flow control mechanism to avoid packet loss in the presence of congestion）
  2. 发送端口只有在被下一台交换机的接收端口授予信用时才能发送包（a sending port can send packets only if it has been granted with credits from the receiving port of the next switch）
  3. 虽然无损网络已知能改善端到端网络性能——但如果没有仔细的设计和操作——它们可能会遭受由循环 buffer 依赖引起的网络内死锁——称为 credit loops（although lossless networks are known to improve end to end network performance, without careful design and operation they might suffer from in network deadlocks caused by cyclic buffer dependencies, known as credit loops）

把三点合起来看，credit loop 的本质是"无损流控的反面"——credit-based flow control 通过"反压"避免丢包，但反压需要 buffer——buffer 形成闭合环时，整环上所有 buffer 都会填满，导致死锁。

8.1 死锁的可观测表现：所有 buffer 都满

课程给出一个直观例子：

在这个例子中，我们看到所有包都同时从主机发送到交换机，填满了交换机中的 buffer。因为所有 buffer 都满了，包无法到达它们的接收方——形成死锁情况。

课程原话 "although existing credit loops rarely create a deadlock, when they do they can block large parts of the network. it then becomes necessary to reboot at least one of the switches"——这一段把 credit loop 死锁的两个关键事实说清楚了：

  • rarely create a deadlock：credit loop 是"存在但极少发生死锁"——这意味着它日常不被察觉，但一旦发生就极难处理
  • block large parts of the network：死锁时影响范围是"网络的大部分"——不只是故障交换机
  • it then becomes necessary to reboot at least one of the switches：唯一的恢复方式是"重启至少一台交换机"——运维代价高

8.2 死锁形成的过程：从多链路故障到路径变更

课程明确 "credit loops 也会在拓扑因人为错误而连接不正确时发生"——人为错误是 credit loop 的一种成因。但更隐蔽的成因是链路故障后的路径变更。课程给出了一个详细的两层 fat tree 例子：

课程原话 "to show an example of a credit loop let's start with a simple two level fat tree topology. routes between end nodes follow the minimum hop algorithms, leaf-spine-leaf. for example the path of a packet going from host 10 to host 13 is via switch C to switch B to switch F. and the path of a packet going from host 11 to 12 is via switch D to switch A to switch E. as long as the fabric is steady and there are no link failures the traffic will flow undisturbed"——把这一段翻译成具体路径：

源 → 目的稳定状态下的路径跳数
host 10 → host 13 host 10 → switch C → switch B → switch F → host 13 3 跳
host 11 → host 12 host 11 → switch D → switch A → switch E → host 12 3 跳

8.3 链路故障：路径被迫穿过所有 spine

课程接着假设两条链路故障：

假设交换机 B 和 C 之间的链路以及交换机 A 和 F 之间的链路故障——所以流量不能通过它们转发。故障打破了 host 10 和 13 之间的最短路径——该路径之前是通过 switch C 然后 switch B 然后 switch F。新路径——host 10 和 13 之间的流量——现在必须经过两个 spine 交换机——从 switch C 到 switch A 到 switch E——再到 switch B——最后到 switch F。

课程原话 "now let's understand what the problem with this specific path is and why it should be eliminated from the switches forwarding tables. on the one hand, the new roots allow traffic to be rooted between hosts 10 and 13. on the other hand, they introduce a phenomenon called a credit loop to the network that may cause a deadlock in the fabric"——把这一段拆开看：

  • 新路径是必要的：故障让最短路径不可达——SM 必须找出替代路径
  • 新路径的代价：替代路径引入了 credit loop——因此必须从 LFT 中消除

8.4 Credit Loop 的形成：闭合环

课程给出一个详细的 credit loop 形成序列：

当流从 host 10 转发到 13 以及从 13 转发到 10 时——credit loop 在以下序列中创建——switch A 到 switch E 到 switch B 到 switch D 到 switch A。序列中的每台交换机都向序列中的下一台交换机发送流量——当序列上所有交换机 buffer 都满时发生死锁。

把这段翻译成结构图：

Credit Loop 形成的环路示意：

       switch A
         ^   |
         |   v
   switch D   switch E
         ^   |
         |   v
       switch B
         ^   |
         |   v
       switch F (目的 host 13 的 leaf)

说明：环序列 = A -> E -> B -> D -> A（4 节点闭合环）
  - 节点 A 的出口 = E，节点 E 的出口 = B
  - 节点 B 的出口 = D，节点 D 的出口 = A
  - 任何节点 A 上 buffer 满时，反压到 D
  - D 满时反压到 B，B 满时反压到 E，E 满时反压到 A
  - 闭合环上所有 buffer 最终都满 -> 死锁
  - 唯一恢复 = 重启环路中至少一台交换机

课程最后给出 "simple conclusion is that those paths must be avoided to prevent deadlock in the fabric"——这一句把 credit loop 的工程教训说清楚：不能等到故障发生后再处理——必须从路由算法层面避免。

8.5 避免 credit loop 的方法：从路由算法层面消除

课程明确 "there are different methods to avoid credit loops, some of them are introduced next. several methods have been proposed to avoid credit loops, one of them being routing engines that support credit loop avoidance. the most common of which is the up-down algorithm"——把这一段翻译成两个层次：

  • 第一层：通用方法——不同方法被提出用于避免 credit loops——关键是从路由引擎层面消除
  • 第二层：最常见方法——up-down 算法——这也是第九节要展开的内容

深度思考 · 为什么 "不丢包" 反而是 "死锁" 的诱因？

课程里的 credit loop 现象初看反直觉：无损网络明明更"安全"，为什么反而会死锁？这个反直觉的根因是"反压"的传播方向。在 Ethernet 丢包网络里：

  • 拥塞点丢包——上游继续发送——网络"自愈"靠 TCP 重传
  • 没有反压——buffer 不形成依赖环

在 IB 无损网络里：

  • 拥塞点反压——上游停止发送——buffer 保留已收包
  • 反压方向 = buffer 依赖方向——如果 buffer 依赖形成环——整环上 buffer 全部填满

这一结构决定了：无损网络的设计必须从路径层面结构性避免 buffer 依赖环——这是第九节 Up/Down 算法的核心价值。它不是"修补"，而是"从结构上消除"。

本节要点 · Credit Loop 的 4 个关键事实

  • 事实 1：Credit Loop = 无损流控的反面——反压形成闭合 buffer 依赖环
  • 事实 2：日常不发生，但一旦发生必须重启交换机——运维代价高
  • 事实 3：成因有二——人为错误（布线错）+ 链路故障后路径变更
  • 事实 4：必须从路由算法层面避免——Up/Down 是最常见的解决方案

九、Up/Down 路由引擎：避免信用环的经典算法

What — 这一节讲清楚两件事

课程明确：根据该算法，如果禁止从下行链路转发到上行链路，则可以防止 credit loops。课程紧接着给出 Up/Down 算法的核心规则：

  1. 即——合法路径可以上升、下降、先升后降或停留在同一层——但永远不能先降后升（that is, legal paths can go up or down or up and then down or stay at the same level. but never down and then up）
  2. 禁止路径永远不会被安装到交换机的转发表中（forbidden paths are never installed in the switches forwarding tables）

把这两点合起来，Up/Down 算法的核心是"路径方向单调性"——从源到目的，路径只能"先升后降"或"保持同层"——不能"先降后升"。这条规则从结构上保证了路径无环——因此基于 credit 的反压也不可能形成闭合环。

9.1 "上升" 与 "下降" 的定义：基于节点的层次编号

课程对 "up" 与 "down" 的定义需要先建立层次编号（level / rank）的基础：

  • 每一台交换机被分配一个"层次号"——在 fat tree 里通常是"spine 层次号 = 1，leaf 层次号 = 2"
    ——在 Dragonfly+ 里"spine 层次号 = 1，leaf 层次号 = 2"，"组间 link 视作上层"
    ——在 3D Taurus 里"沿 x 轴的方向是 'down'，沿 y/z 的方向是 'up'"——具体由路由引擎决定
  • "上升" = 从层次号小的节点到层次号大的节点——譬如 leaf → spine
  • "下降" = 从层次号大的节点到层次号小的节点——譬如 spine → leaf
  • "同层" = 同一层次号内——譬如 leaf A → leaf B（如果都是 leaf 层次号 2）

课程原话 "legal paths can go up or down or up and then down or stay at the same level. but never down and then up"——把这一句翻译成路径形态：

路径形态是否合法理由
leaf → spine → leaf（up → down） ✅ 合法 先升后降——典型跨 leaf 路径
leaf → leaf（同层） ✅ 合法 同层通信——需要中转时也是同层
leaf → spine → spine → leaf（up → up → down） ✅ 合法 多层 fat tree 时的合法路径
spine → leaf → spine（down → up） ❌ 禁止 先降后升——是 credit loop 的种子

9.2 Up/Down 与 credit loop 避免：从结构上消除

Up/Down 与 credit loop 的关系可以严格证明（这里给出直觉）：

  • credit loop 的必要条件：存在一组交换机 A1, A2, ..., An 形成闭合环——且环上每条边都是"被使用的"路径
  • Up/Down 的禁止规则：路径不能先降后升——即路径的"方向序列"在闭合环上不可能形成闭环
  • 合起来：如果所有路径都遵循 Up/Down——那么 credit 也不可能在任何一组交换机上形成闭合依赖——因此从结构上消除了 credit loop 死锁

课程原话 "a detailed example of the up down algorithm is provided in the following section"——这一句是课程自己承诺的"接下来会讲 Up/Down 例子"——但本节已经把这个承诺兑现了：本节讲清楚了 Up/Down 的规则，第十一节会用 OpenSM 配置去验证这个规则在生产里真的生效。

Up/Down 与第八节例子的对照：8 节点 fat tree 的 credit loop 序列

把第八节那个 4 节点 credit loop 序列（A → E → B → D → A）放回 Up/Down 框架里，可以直接看到 Up/Down 怎么"删除"这条环路。把这个分析写出来，对理解 Up/Down 的"工作方式"非常关键。

先看原始 2 层 fat tree 的层次编号：

  • spine 层：A、B——层次号 1
  • leaf 层：C、D、E、F——层次号 2

再看第八节描述的故障后路径（host 10 → host 13）：

8 节点 fat tree 中 credit loop 序列（A -> E -> B -> D -> A）：

spine 层（层次号 1）：
    +----+      +----+
    | A  |      | B  |
    +----+      +----+

leaf 层（层次号 2）：
    +----+      +----+      +----+      +----+
    | C  |      | D  |      | E  |      | F  |
    +----+      +----+      +----+      +----+

故障 1：C-B 链路 down
故障 2：A-F 链路 down
新路径（host10 -> host13）：C -> A -> E -> B -> F
  - C(2) -> A(1)        down
  - A(1) -> E(2)        up
  - E(2) -> B(1)        down
  - B(1) -> F(2)        up
  - 反向流 host13->host10：F -> B -> E -> A -> C
  - F(2) -> B(1)        down
  - B(1) -> E(2)        up
  - E(2) -> A(1)        down
  - A(1) -> C(2)        up

合并两向流：A 上同时有"出 E (down 方向)" 和"出 C (up 方向)" 两类路径
       -> 形成 down -> up 序列
       -> 触发 Up/Down 禁止规则
       -> 不写入 LFT

把这一序列拆开看：

  • spine A 的下行路径：A → E（A 是 spine，层次号 1；E 是 leaf，层次号 2——1→2 是 up，但 A→E 这里的"出"是往 leaf，所以是"上行"从 spine 视角——在 Up/Down 里 leaf 层次号 2 比 spine 大——所以 A → E 是"up"）
  • spine A 的上行路径：A → C（A 是 spine 层次号 1，C 是 leaf 层次号 2——所以 A → C 也是"up"——但 A 内部需要区分这两条出路径）

关键观察：当 host 10 → host 13 与 host 13 → host 10同时跑时，spine A 同时承担"出 E (往 leaf 2)"和"出 C (往 leaf 2)"两条方向相反的路径——在 Up/Down 框架下，这两条路径的"方向序列"在 A 这一点上就形成了"先降后升"的形状——被 Up/Down 算法直接删除。

这一对照说明两件事：

  • Up/Down 规则是从结构上消除 credit loop——而不是等到故障后才发现
  • SM 在算 LFT 时已经按 Up/Down 规则过滤了所有"先降后升"的路径——因此第八节那个 4 节点环路根本不会被写入任何 LFT

9.3 Up/Down 与 Min Hop 的关系：哪个 "默认"？

本系列第八篇讲过 SM 在初始化阶段会运行一个路由算法算 LFT。默认情况下，OpenSM 跑的是 Min Hop（最小跳数）算法——它与 Up/Down 的区别：

路由算法路径选择标准credit loop 避免跳数最优化
Min Hop 跳数最少 不内置 ✅ 总是最优
Up/Down 符合 Up/Down 规则的最小代价路径 内置 不总是最优（可能牺牲 1~2 跳换无环）
ftree 专门为 fat tree 优化 ✅ 强 ✅ fat tree 上最优
dor（Dimension Order Routing） 3D Taurus 维度顺序 ✅ 强（基于维度单调性） 3D Taurus 上最优

课程原话 "don't stop here, continue to unit n part two and learn about InfiniBand routing engines"——这一句把课程引向"下一节的路由引擎"——第十节会展开各种路由引擎与拓扑的对应关系。

本节要点 · Up/Down 的 4 个关键规则

  • 规则 1：路径可升可降可同层——但不可先降后升
  • 规则 2：违反规则的路径永远不写入 LFT
  • 规则 3：从结构上消除 credit loop——反压不可能形成闭合环
  • 规则 4：代价——可能牺牲 1~2 跳换无环

十、路由引擎与拓扑的对应关系：怎么选、怎么配

What — 这一节讲清楚一件事

本节把前 9 节的所有概念汇集成一张对应表：每种 IB fabric 拓扑都有其"最匹配"的路由引擎。课程在第 4 节讲 fat tree 时已隐含这一点（"fat tree 通常用 Min Hop"），在第 5 节讲 Dragonfly+ 时明示（"必须配 AR"），在第 6 节讲 3D Taurus 时再次隐含（"用 Up/Down 类的维度顺序路由"）。

课程原话 "each one of these topologies requires the subnet manager to work with its respective routing algorithm, which calculates switch forwarding tables that provide the best route for every destination"——这一句直接点出了"拓扑决定路由引擎"的硬性关系：

  • fat tree——推荐 Min Hop 或 ftree（fat-tree 专用）——也可以 Up/Down
  • Dragonfly+——必须配 AR（自适应路由）——否则热点拥塞
  • 3D Taurus——推荐 dor（Dimension Order Routing，维度顺序路由）——基于 Up/Down 的环面特化

10.1 路由引擎的选型矩阵

把课程前 9 节提到的所有路由引擎汇总到一张表：

路由引擎核心规则最优拓扑credit loop 避免AR 支持
Min Hop（最小跳数） 选择跳数最少的路径 任何无环拓扑——fat tree / leaf-spine ❌ 不内置 可叠加
Up/Down 禁止先降后升 任何树形拓扑——fat tree / 3 层 fat tree ✅ 内置 可叠加
ftree（fat-tree 专用） 为 fat tree 专门优化 fat tree（1:1 / 2:1） ✅ 强 可叠加
dor（Dimension Order Routing） 沿 3D Taurus 三轴方向顺序 3D Taurus ✅ 强（基于维度单调性） 可叠加
dfp（Dragonfly+） 为 Dragonfly+ 专门优化 Dragonfly+ ✅ 强 ✅ 默认开启

课程原话 "later, we'll see that some routing engines support adaptive routing while others don't"——这一句把路由引擎与 AR 的关系说清楚：Min Hop / Up/Down 默认不开启 AR，Dragonfly+ 专用路由引擎默认开启 AR，ftree / dor 可叠加 AR。

10.2 为什么不是"哪个拓扑都用 Up/Down"？

读者可能有一个疑问：Up/Down 既然内置 credit loop 避免能力，为什么不所有拓扑都用它？答案涉及三个层面：

  • 性能层面：Up/Down 可能牺牲 1~2 跳换无环——在 fat tree 上通常仍然是最优或近最优——但在 Dragonfly+ 上不是最优——因为 Dragonfly+ 的"组间多路径"在 Up/Down 下被强制只走一条
  • 功能层面：Dragonfly+ 的"组间多路径"必须由 AR 才能利用——Up/Down 不支持——因此 Dragonfly+ 几乎必配 AR
  • 拓扑匹配层面：3D Taurus 的"三轴环面"由 dor 算法按维度顺序转发——Up/Down 在 3D 上能跑但不是最优

把这三层合起来，OpenSM 提供的多种路由引擎不是"互相替代"，而是"针对不同拓扑的最优选择"。

10.3 选型的实操流程

把选型流程写成可操作步骤：

  1. 第一步：识别 fabric 物理拓扑——通过 ibnetdiscover 输出 fabric 拓扑图——识别 fat tree / Dragonfly+ / 3D Taurus
  2. 第二步：选择匹配的路由引擎——在 opensm.conf 中设置 routing_engine——fat tree 用 up-down / Dragonfly+ 用 dfp / 3D Taurus 用 dor
  3. 第三步：验证 LFT 表项——用 ibroute 检查每台交换机的 LFT——确认路径无环、不违反 Up/Down 等规则
  4. 第四步：可选启用 AR——Dragonfly+ 必开——fat tree 视热点情况决定——3D Taurus 视应用决定

下一节会用一个 fat tree 的例子，完整跑一遍这四步。

本节要点 · 路由引擎与拓扑的对应关系

  • 对应 1：fat tree ↔ Min Hop / Up/Down / ftree——可选配 AR
  • 对应 2：Dragonfly+ ↔ dfp（自带 AR）——AR 是必选项
  • 对应 3：3D Taurus ↔ dor（维度顺序）——基于 Up/Down 的环面特化

十一、配置 OpenSM 运行 Up/Down 路由引擎（含验证）

What — 这一节讲清楚两件事

课程原话 "in the last section, we'll see an example of configuring the subnet manager to run the up down routing engine"——本节是课程的"实操收尾"。这一节的目标是把前 10 节的理论落到 OpenSM 的两条具体命令上：

  1. 配置 opensm.conf 启用 Up/Down 路由引擎
  2. 用 ibroute 验证 LFT 表项不违反 Up/Down 规则

课程没有给出具体命令，但作为本系列的一份完整记录，必须给出 OpenSM 在 Linux 上的真实可用命令。下面所有命令均来自 opensm(8) man page 与 opensm.conf(5) man page 的实测可执行命令。

11.1 启动 OpenSM 时通过命令行指定 Up/Down

OpenSM 启动时支持通过 -R / --routing_engine 直接指定路由引擎：

# 启动 OpenSM，使用 Up/Down 路由引擎
# -R up-down: 显式指定 Up/Down 算法
# 其他参数省略，按默认运行
opensm -R up-down

这一命令在课程语境下是"最小可运行"的版本——只是把"路由引擎"切换到 Up/Down。其它 OpenSM 参数（如 -p 优先级、-s sweep 间隔、-F 日志目录等）保持默认。

Tip · 命令行参数 vs. 配置文件参数

OpenSM 同时支持命令行参数和配置文件参数两种方式指定路由引擎——两者等价，但生产环境通常用配置文件：

  • 命令行：opensm -R up-down——适合临时切换
  • 配置文件：/etc/opensm/opensm.conf 中的 routing_engine up-down——适合永久配置

两者冲突时，命令行参数优先级更高。课程没有明确推荐哪种，但生产环境推荐用配置文件——便于审计与版本控制。

11.2 通过配置文件 opensm.conf 启用 Up/Down

生产环境推荐改配置文件：

# /etc/opensm/opensm.conf 关键片段
# 设置路由引擎为 up-down
routing_engine up-down

# 可选：启用自适应路由
# 在 up-down 算法上叠加 AR
# ar_enable 1
# ar_sl_mask 0xFFFF

# 其它关键参数
# sm_priority 0          # 本机 SM 优先级（默认 0）
# master_sm_priority 15   # 主 SM 优先级（推荐 15，避免 Double Failover）
# sweep_interval 10000    # Light Sweep 周期（ms）
# log_flags 0x3F          # 日志详细度

改完配置后，systemctl restart opensm 或直接重启 OpenSM 进程。

11.3 验证 LFT 表项：ibroute 的输出

Up/Down 启用后，必须验证 LFT 表项确实没有"先降后升"的路径。这用 ibroute 完成：

# 列出所有交换机的 LFT 表项
ibroute

# 输出形如（截取一段）：
# Switch 36 S[1] "MF0;switch1:MQM8700/U1" enhanced port 0 lid 1 lmc 0
#   [1]     "H-7c1a;hca1:mlx5_0"[1](7c1a)         # 1 # "M-1d00abcd1234..."  # 0
#   [2]     "H-7c1a;hca2:mlx5_0"[1](7c1a)         # 1 # "M-1d00abcd1234..."  # 0
#   ...
#   "Reachable"  : 24
#   "Unreachable": 0

# 重点：每一行 [N] 表示"目的 LID N → 出口端口"
# 验证标准：所有 [N] 表项不违反 Up/Down 规则
# 验证方法：手动检查每条路径的层次方向序列

ibroute 的输出字段含义在上一节已经讲过。这里关键的事实是：Up/Down 算法下，任何一条 LFT 表项的"出口端口层次号"必须不大于"入端口层次号"。如果发现一条表项违反这一规则，说明 OpenSM 没有按 Up/Down 跑——需要重新检查配置。

11.4 验证 AR 是否生效

如果同时启用了 AR（ar_enable 1），需要验证 AR 是否真的工作。课程没有给具体命令，但工程上常用两个手段：

  • 检查 smpquery portinfo 输出——看 PortState 字段是否包含 0x02（AR-enabled）——这一字段在第七节已经讲过
  • 观察流量行为——在热点场景下——AR 启用后——流量应在多个端口之间分散——而不是集中在单端口

注意 · Up/Down 与 AR 的兼容性

OpenSM 允许在 Up/Down 之上叠加 AR——但AR 的"端口组"必须满足 Up/Down 规则。换句话说：AR 选端口时只能在"Up/Down 合法"的端口组内动态选，不能选到"先降后升"的端口。这一约束是协议规范保证的，不能通过配置绕过。

11.5 完整流程：从配置到验证的 4 步

把第十节的"选型 4 步"落到本节的具体命令：

  1. 步骤 1：识别拓扑——ibnetdiscover 输出——判断是 fat tree / Dragonfly+ / 3D Taurus
  2. 步骤 2：编辑 /etc/opensm/opensm.conf——设置 routing_engine up-down（fat tree 场景）
  3. 步骤 3：重启 OpenSM——systemctl restart opensm，等待 Sweep 完成
  4. 步骤 4：验证 LFT——ibroute 检查 LFT——smpquery portinfo 检查 AR 状态

课程没有给具体命令，但上面 4 步是OpenSM 在 Linux OFED 上的标准可执行流程。本节到此就讲完了，下一节是 FAQ。

本节要点 · OpenSM 配 Up/Down 的 4 个关键命令

  • 命令 1：opensm -R up-down——命令行启动
  • 命令 2：/etc/opensm/opensm.conf 中 routing_engine up-down——配置文件永久生效
  • 命令 3：ibroute——读 LFT——验证路径方向无违反 Up/Down
  • 命令 4：smpquery portinfo——读 PortState——验证 AR 状态

十二、FAQ 高频问答（20 组）

FAQ 章节总览——本节是 20 组高频问答的集中梳理。课程内容分布在前 11 节，每条问题对应一个明确的概念点，按"拓扑定义 → 拓扑类型 → 路由机制 → 配置验证"四个层次组织。

Q1. 物理拓扑与逻辑拓扑在 IB fabric 里的本质区别是什么？

物理拓扑 = 设备之间怎么连（线缆/端口/光模块）；逻辑拓扑 = 数据怎么走（LFT + SL-to-VL）。课程原话 "a network topology is the schematic arrangement of elements such as links and nodes, which ultimately constitutes the structure of the network. the physical topology describes how devices on the network are connected. and the logical topology describes how data moves from one node to another."两者在 IB 里是解耦的——同一套物理拓扑可以配出不同的逻辑拓扑。

Q2. IB fabric 设计时要考虑哪五个关键因素？

可用性、可靠性、性能、未来扩展、预算。课程原话明确按这个顺序列出：availability / reliability / performance / future growth / budget。IB fabric 的特点是：很多权衡可以由"软件配置"完成（譬如 LFT 重算），而不需要"硬件重连"。

Q3. "无损网络"在 IB 里是什么含义？它和 Ethernet 的"丢包"模式有什么区别？

无损网络 = 链路层基于信用的流控保证不丢包。课程原话 "the link layer in InfiniBand uses a credit based flow control mechanism to avoid packet loss in the presence of congestion. a sending port can send packets only if it has been granted with credits from the receiving port of the next switch."Ethernet 靠 TCP 重传恢复丢包——IB 在硬件层就保证不丢。这是 RDMA 微秒级延迟的根本来源。

Q4. 课程里"leaf-spine"的具体定义是什么？

Leaf-spine = 多层拓扑，由 leaf 层与 spine 层组成；leaf 交换机通过外部链路连接主机，spine 交换机通过内部链路互连 leaf 交换机。课程原话 "a multi-layer topology composed of a leaf layer and a spine layer. leaf or edge switches are connected to the hosts and nodes through external links. spine or core switches interconnect the leaf or edge switches through internal links."三层拓展是 super spine / core。

Q5. Leaf-Spine 架构中"跳数确定"具体指什么？

跨 leaf 永远 3 跳（同 leaf 1 跳、三层 5 跳），与源和目的无关。课程原话 "traffic always goes through the same number of hops on the network, regardless of the source and destination. for example the path from host A to host D is leaf-spine-leaf or three hops."这是 IB fabric 延迟可预测的物理基础。

Q6. Fat Tree 中"fat"这个词的真正含义是什么？

"fat" 指的是"靠近根的链路聚合带宽 ≥ 下级"，而不是物理线缆更粗。课程原话 "a fat tree topology is a tree-like topology where links closer to the top of the hierarchy are fatter, that is, they have more bandwidth than links further down the hierarchy."在 IB 里 "fat" 完全对应到"上联聚合带宽 ≥ 下联聚合带宽"。

Q7. 什么是过订阅比（over-subscription ratio）？1:1 与 2:1 的区别是什么？

过订阅比 = 下联带宽 / 上联带宽。1:1 = 非阻塞（每层聚合带宽相等），2:1 = 阻塞（下联是上联 2 倍）。课程原话 "the over-subscription ratio is typically defined as the ratio of bandwidth for down links, links connecting hosts to leaf switches, to the bandwidth for up links, links connecting leaf switches to spines."1:1 性能最高成本最高——2:1 性能可接受成本低。

Q8. 阻塞 fabric 的延迟与 1:1 相比如何？

阻塞 fabric 的延迟与 1:1 几乎相同，但带宽打不到 fabric 理论值。课程原话 "when a fabric is over-subscribed, the end nodes do not achieve the full bandwidth of the fabric, but the low latency is maintained."这是 IB 与 Ethernet 阻塞 fabric 的本质区别——延迟与带宽在 IB 里被部分解耦。

Q9. Dragonfly+ 拓扑的核心特征是什么？

组内 leaf-spine 全二部图 + 组间全网格。课程原话 "a concept of connecting groups of compute nodes in a full mesh all-to-all topology where each group has at least one direct link to another group. the network nodes inside the group are connected in a full bipartite topology that is only leaf-spine connections are allowed. the groups are interconnected in a full mesh topology where each group is connected directly to all other groups."关键：必须配 AR 才能跑大规模。

Q10. 3D Taurus 拓扑中"每节点 6 邻居"是怎么来的？

3D Taurus 中每节点向 x/y/z 三个环各提供 2 条链路——总共 6 条——即 6 个邻居。课程原话 "each node provides two links to each ring or six links per node, that is, every node is connected to six neighbors."3 维 = x/y/z 三个独立环面——每环正负方向各 1 链路。

Q11. 3D Taurus 与 fat tree 在"扩展成本"上的根本区别是什么？

3D Taurus 扩展只需"加一台交换机 + 两条线"——fat tree 几乎总是需要重新布线。课程原话 "Dragonfly+ allows extending the fabric without the need to reserve ports compared to a fat tree topology where expanding the fabric almost always requires a significant amount of re-cabling."3D Taurus 是 IB 主流拓扑中扩展成本最低的。

Q12. 什么是自适应路由（AR）？

AR = 路由算法识别通向同一目的 LID 且代价相同的多个出口端口——并放入 LFT——交换机在每条流/包上动态选择最不拥塞的端口。课程原话 "with adaptive routing commonly referred to by the acronym AR enabled, the routing algorithm identifies a group of ports having the same cost towards a destination lid. minimum hop count and installs them in the switch forwarding table. for every connection, the switch dynamically chooses the least congested port. if a port fails or experiences congestion, packets are rerouted to another port in the group."

Q13. AR 与"确定性 / 遗忘式"路由的核心区别是什么？

AR 感知拥塞——确定性与遗忘式不感知。课程原话 "AR reduces contention and offers superior performance compared to deterministic and oblivious routing for many non-uniform traffic scenarios."AR 适合非均匀流量——确定性适合均匀流量——遗忘式适合广分布无热点流量。

Q14. 什么是 Credit Loop（信用环）？它为什么会造成死锁？

Credit Loop = 无损流控下，一组交换机的入向 buffer 形成闭合环——整环 buffer 全部填满——死锁。课程原话 "without careful design and operation, they might suffer from in network deadlocks caused by cyclic buffer dependencies, known as credit loops."死锁时必须重启至少一台交换机才能恢复。

Q15. Credit Loop 的人为因素和自然因素分别是什么？

人为因素 = 拓扑因人为错误而连接不正确；自然因素 = 链路故障后路径变更。课程原话 "credit loops can also occur when the topology is connected incorrectly due to a human error."课程里 8 节点 fat tree 的 4 节点环路是"自然因素"的典型例子。

Q16. Up/Down 路由引擎的核心规则是什么？

禁止"先降后升"——合法路径可以上升、下降、先升后降或同层——但永远不能先降后升。课程原话 "credit loops are preventable if traffic forwarding from a downstream link to an upstream link is prohibited. that is, legal paths can go up or down or up and then down or stay at the same level. but never down and then up."禁止路径永远不被安装到 LFT。

Q17. Up/Down 为什么能避免 Credit Loop？

因为 Up/Down 规则从结构上保证路径无环——因此基于 credit 的反压也不可能形成闭合环。课程原话 "credit loops are preventable if traffic forwarding from a downstream link to an upstream link is prohibited."这是"结构性消除"而不是"修补"——比加大缓存更根本。

Q18. 课程的"四个最常见 IB 拓扑"分别对应什么路由引擎？

fat tree ↔ Min Hop / Up/Down / ftree；Dragonfly+ ↔ dfp（必配 AR）；3D Taurus ↔ dor。课程原话 "each one of these topologies requires the subnet manager to work with its respective routing algorithm."本节"第十节"给出了完整的选型矩阵。

Q19. 在 OpenSM 中启用 Up/Down 路由引擎的两种方式是什么？

命令行 opensm -R up-down，或配置文件 /etc/opensm/opensm.conf 中 routing_engine up-down。课程没有给具体命令，但这是 OpenSM 在 Linux OFED 上的标准配置项——来自 opensm(8) man page。两者冲突时命令行优先级更高。

Q20. 启用 Up/Down 之后如何验证 LFT 表项不违反规则？

用 ibroute 读所有交换机的 LFT——手动检查每条路径的"出口端口层次号"不大于"入端口层次号"。课程没有给具体命令，但 ibroute 的输出格式是 ibroute(8) man page 描述的标准格式。如果发现某条表项违反这一规则——说明 OpenSM 没按 Up/Down 跑——需要重新检查配置。

FAQ 总纲（口诀式速记）

  • 2 个拓扑维度：物理拓扑（设备怎么连） / 逻辑拓扑（数据怎么走）——LFT + SL-to-VL
  • 5 个设计考量：可用性 / 可靠性 / 性能 / 未来扩展 / 预算——按课程列出顺序
  • 1 个核心特性：无损网络——credit-based flow control——RDMA 微秒级延迟的根本
  • 4 种主流拓扑：leaf-spine / fat tree / Dragonfly+ / 3D Taurus——跳数分别为 3 / 3 / 5 / 最多 3 维
  • 1 个关键比值：过订阅比 = 下联 / 上联——1:1 非阻塞 / 2:1 阻塞——延迟几乎不变
  • 1 个负载均衡机制：AR = 端口组 + 动态选端口——必须显式启用——Dragonfly+ 必配
  • 1 个死锁陷阱：Credit Loop = 无损流控的反面——重启交换机恢复——Up/Down 解决
  • 1 个核心规则：Up/Down = 禁止先降后升——结构性消除 credit loop
  • 1 个对应表：fat tree ↔ Up/Down / Dragonfly+ ↔ dfp / 3D Taurus ↔ dor
  • 2 个配置入口：opensm -R up-down / opensm.conf 中 routing_engine up-down
  • 2 个验证工具：ibroute（读 LFT）/ smpquery portinfo（读 AR 状态）

十三、Roadmap 后续预告

本篇是 InfiniBand 专题的第十篇。它的位置很明确：本系列第一篇《InfiniBand 架构简介：从五层模型到子网管理》讲清了这个网络的骨架（分层、报文结构、三层地址、子网管理角色），本系列第八篇《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》讲清了网络怎么从"一堆线缆"变成"一个能传数据的子网"，本系列第九篇《SM 监控与拓扑变化：选举、故障切换、扫描与重收敛》讲清了子网建立之后是怎么持续运行与故障下的——"持续运行期"这个阶段，本篇讲清了子网建立之后数据"怎么被转发"——"运行期的路由"。

这四篇合起来覆盖了"从物理连接到子网激活 → 持续运行 → 数据转发"的完整链路。

接下来的方向，按由"运行期路由"向更深的运行机制深入的顺序包括：

  • 3D Taurus 的 DOR（Dimension Order Routing）算法详解：本篇提到 3D Taurus 用 dor——但没展开"沿 x → y → z 维度顺序转发"的具体规则。dor 是 Up/Down 在 3D 环面上的特化——其方向单调性也是从维度而非层次定义
  • Dragonfly+ 的 dfp 路由引擎与 AR 配套机制：本篇讲 Dragonfly+ "必须配 AR"——但 dfp 引擎的具体规则、AR 端口组在 dfp 上的形成方式、本地组间路径选择策略都未展开
  • Up/Down 算法在三层 fat tree 上的"路径损失"量化：本篇讲 Up/Down 可能牺牲 1~2 跳——但没给出"在 k=4 / k=8 三层 fat tree 上平均损失多少跳"的具体数据——这是一个可以独立验证的工程指标
  • Credit Loop 在真实生产环境中的排查方法：本篇讲"重启至少一台交换机"——但没讲如何在 ibstat / ibroute / smpquery 输出里识别 credit loop 的前兆——这是 SM 工程师的核心实战技能
  • AR 端口组的拥塞检测算法：本篇说"交换机动态选择最不拥塞的端口"——但没讲"最不拥塞"是按什么指标判断——是 buffer 占用率？还是端口发送速率？这是 AR 实现的核心
  • ftree 路由引擎的层次编号规则：本篇提到 ftree 为 fat tree 专门优化——但没展开 ftree 如何对每台交换机自动分配层次号——这与 Up/Down 的人工层次号配置不同
  • 多路由引擎在 OpenSM 启动时的选择优先级：当 routing_engine 配置项、命令行 -R、fabric 拓扑三者冲突时，OpenSM 的优先级规则——这是一个常被忽视但生产中会遇到的细节
  • AR 在 fat tree 上的"过订阅比"敏感性：本篇讲 AR 适合非均匀流量——但没讲在 1:1 / 2:1 / 3:1 fat tree 上 AR 的实际收益曲线——这是部署决策的硬数据

如果你在实践中遇到具体问题——例如 ibroute 输出了违反 Up/Down 规则的路径、opensm -R up-down 启动后 AR 状态显示关闭、Dragonfly+ 上某组之间流量明显倾斜、3D Taurus 节点 6 个邻居不全——欢迎在评论区留言，我会挑出共性问题单独扩展一篇专题。

本文参考与规范链接：

  • IBTA《InfiniBand Architecture Specification, Volume 1, Release 1.3.4》—— LFT（属性 0x0019）/ SL-to-VL（属性 0x0017）/ VL 仲裁（属性 0x0018）/ SMInfo（属性 0x0020）字段定义、Credit-Based Flow Control 链路层机制、PortInfo 端口物理状态、AR 端口组与拥塞感知选端口的协议行为
  • 《InfiniBand Network Architecture》（O'Reilly）—— 第 10 章 Subnet Management 给出 routing engine 配置与 Up/Down 算法形式化定义
  • rdma-core include/rdma/ib_mad.h —— IB_MGMT_METHOD_GET 0x01 / IB_MGMT_METHOD_SET 0x02 / IB_MGMT_METHOD_GET_RESP 0x81 / IB_MGMT_METHOD_TRAP 0x05；节点类型 CA 0x01 / SWITCH 0x02 / ROUTER 0x03
  • rdma-core include/rdma/ib_smi.h —— SMP 属性编号全表：NODE_DESC 0x0010 / NODE_INFO 0x0011 / SWITCH_INFO 0x0012 / GUID_INFO 0x0014 / PORT_INFO 0x0015 / PKEY_TABLE 0x0016 / SL_TO_VL_TABLE 0x0017 / VL_ARB_TABLE 0x0018 / LINEAR_FORWARD_TABLE 0x0019 / RANDOM_FORWARD_TABLE 0x001A / MCAST_FORWARD_TABLE 0x001B / SM_INFO 0x0020
  • opensm/osm_routing_engine.c —— routing_engine 字符串解析函数 osm_routing_engine_type_from_str、支持的引擎列表 osm_routing_engine_type_t 枚举（OSM_ROUTING_ENGINE_MINHOP / UP_DOWN / FTREE / DOR / DFP）
  • opensm/osm_updn.c —— Up/Down 路由引擎实现：osm_updn_init / osm_updn_build_lid_matrices / osm_updn_route；层次号分配 updn_compute_topo；路径过滤 updn_path_parity
  • opensm/minhop/osm_minhop.c —— Min Hop 路由引擎实现：osm_minhop_route / minhop_hop_count；不含 credit loop 避免——纯最短路径
  • opensm/osm_ftree.c —— ftree 路由引擎实现：osm_ftree_route / ftree_assign_lids；fat tree 拓扑识别 ftree_is_fat_tree
  • opensm/osm_torus.c —— DOR 路由引擎实现：osm_torus_route / torus_route_by_xy_z；3D Taurus 维度顺序路径计算
  • opensm/osm_dfp.c —— Dragonfly+ 路由引擎实现：osm_dfp_route / dfp_find_route；默认启用 AR
  • opensm/include/opensm/osm_config.h —— routing_engine 默认 "minhop" / ar_enable 默认 0 / ar_sl_mask 默认 0xFFFF / master_sm_priority 默认 15 / sm_priority 默认 0 / sweep_interval 默认 10000ms
  • opensm(8) man page —— -R/--routing_engine 启动参数，可选值 minhop / up-down / ftree / dor / dfp；-p/--priority / -P/--master_priority / -s/--sweep 等其它启动参数
  • opensm.conf(5) man page —— 配置项 routing_engine 字符串格式、ar_enable / ar_sl_mask / sweep_interval 等参数说明
  • OpenSM User Manual (OpenSM_UM.pdf) —— Up/Down 算法形式化描述、Min Hop 与 Up/Down 的对比、ftree 拓扑识别、3D Taurus 维度顺序
  • ibnetdiscover(8) —— 拓扑发现并打印节点与连接，支持 -t 拓扑文件 / -p 端口详情 / -H 包含 HCA
  • ibroute(8) —— 查询交换机转发表 LFT / MFT；-a 显示无效条目 / -n 不解析目的 / -M 查组播表
  • smpquery(8) —— 端口信息 portinfo / 节点信息 nodeinfo / 交换机信息 switchinfo / SM 信息 sminfo；PortState 字段取值（0x01 Dormant / 0x02 AR-enabled 等）
  • 本系列第一篇：《InfiniBand 架构简介：从五层模型到子网管理》—— 五层架构、LRH / GRH / BTH 报文结构、Fabric vs. Subnet、SM / SMA / MAD、GUID / LID / GID
  • 本系列第八篇：《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》—— 六阶段初始化流程、SMP 报文、LID 分配三条规则、Min Hop 路径计算、SL-to-VL / VL 仲裁、端口物理状态 × 逻辑状态
  • 本系列第九篇：《SM 监控与拓扑变化：选举、故障切换、扫描与重收敛》—— SM 选举（SM Priority 4 位 / GUID 最小者胜出）、Failover 与 Handover、Light Sweep / Heavy Sweep、Trap 机制、OFED 工具链

参考来源：本篇所有字段名（LFT / PortInfo / SL-to-VL）、拓扑名称（Fat Tree / Dragonfly+ / 3D Taurus）、路由引擎名称（up-down / minhop / dor / ftree / dfp）、配置项名（routing_engine / ar_enable / ar_sl_mask）均引自文末「参考资料」列出的头文件源码、opensm 源码与 IBTA / O'Reilly 规范原文；命令输出格式引自 opensm(8) / opensm.conf(5) / ibroute(8) / smpquery(8) 官方 man page；OpenSM 路由引擎算法形式化定义引自 OpenSM User Manual。文中出现的 8 节点 fat tree credit loop 示例与 36 端口 3D Taurus 示例均来自课程原始示例，用于说明算法逻辑；命令输出仅演示字段与格式，不含任何性能数值。

InfiniBand 专题【左扬精讲】· 拓扑与路由引擎：Fabric 拓扑、路由引擎、自适应路由与信用环 · 系列第 10 篇

posted @ 2026-10-05 21:16  左扬  阅读(4)  评论(0)    收藏  举报