InfiniBand 专题【左扬精讲】—— InfiniBand MLNX_OFED 到 DOCA-OFED：软件栈统一、安装 Profile 与主机部署验证
InfiniBand 专题【左扬精讲】—— InfiniBand MLNX_OFED 到 DOCA-OFED：软件栈统一、安装 Profile 与主机部署验证
网卡插上了，驱动装了吗？装了，端口为什么还是不通？这是 InfiniBand 现场最常见的一类问题，而它的答案往往不在网络里——在主机侧的软件栈上。本系列前十一篇讲完了协议、报文、传输层、子网管理器、监控、拓扑变化、路由引擎，但它们都默认了一个前提：这台主机的 InfiniBand 驱动、用户态库和管理工具已经就位。这个前提本身不是理所当然的——它由一个正在发生的大版本迁移决定。
本篇是 InfiniBand 专题【左扬精讲】系列的 第 12 篇，主题是MLNX_OFED 到 DOCA-OFED 的迁移：先把 OFED 的来历讲清楚（第一节），再说明 DOCA 原本服务哪一类设备、为什么最终要和 OFED 合并（第二节、第三节），然后把 DOCA-Host 的四个安装 Profile 逐个拆开、并从中筛出适用于 InfiniBand 的那三个（第四节），接着按时间表与操作顺序把整个迁移流程走完——时间表（第五节）、迁移四步（第六节）、前置检查（第七节）、下载选包（第八节）、卸载（第九节）、安装（第十节）、驱动加载（第十一节）、验证（第十二节）。最后单列一节把 IB 特有的风险点挑出来（第十三节），因为"照着通用教程装"在这三个 Profile 上会踩到只有 InfiniBand 才会遇到的坑。
本篇的核心命题只有一句：DOCA-OFED 对 MLNX_OFED 是一比一替代，而不是功能升级。理解这一点之后，"要不要立刻迁移"这个决策就退化成了一道时间题而不是技术题——技术等价已经由 NVIDIA 官方文档写死，剩下的只有 LTS 窗口还剩多少。
开篇必读：课程口语转写里的高频误听，本文全部按官方标识符纠正
本篇素材来自一段英文课程的口语转写，转写引擎对专有名词的还原率很低。照着转写稿敲命令一定敲不通。以下五组对照是全文可复现性的前提：
- "o fed" / "OFED" → OFED（OpenFabrics Enterprise Distribution）。课程把它读成"o fed"，正式名称见 OpenFabrics Alliance 官网。
- "doca OP hed" / "doco ofed" / "dca ofed" → DOCA-OFED。课程口述里出现过至少三种变体，全部指同一个东西。
- "doc a host" / "doke of host" → DOCA-Host。转写把 DOCA 多次听成"doc a" / "doke"。
- "doko rok i" → doca-roce（RoCE，RDMA over Converged Ethernet）。课程把 roce 听成了人名。这是四个 Profile 里唯一不含 InfiniBand 组件的一个，详见第四节。
- "doc ao fed ADDS only networking" → doca-networking。课程把 networking 听成了动词，这是四个 Profile 中最容易被拼错的一个。
另有两处需要单独纠正，因为它们会直接改变操作结果：
- 第四步是"重启系统"还是"重启驱动"，课程与官方文档不完全一致。迁移指南的四步原文是 Reboot your system and verify（重启系统后验证），而安装与升级页给出的加载驱动命令是 /etc/init.d/openibd restart。两者都是官方文档中的表述，适用场景不同。第十一节专门讲这个取舍。
- 课程说"DOCA-Host 有四个安装 Profile"。这句话在课程录制时成立，但当前官方文档已列出五个（新增 doca-host-basic）。第四节把五个都列出，并标明课程口径的适用范围。
本篇核心术语：
OFED OpenFabrics Enterprise Distribution / OpenFabrics Alliance (OFA) 开放结构联盟
Kernel Bypass 内核旁路 / RDMA 远程直接内存访问 / Wire Speed 线速
MLNX_OFED Mellanox 品牌下的 OFED 发行版 / DOCA Data Center On-Chip Architecture
DOCA-Host 统一主机软件包 / DOCA-OFED 与 MLNX_OFED 一比一等价的那个 Profile
DOCA-Core / OVS-DOCA / DOCA Flow / DOCA-PCC / MLNX-DPDK
ConnectX 智能网卡 / BlueField DPU / SuperNIC / VPI 一卡双协议
BlueField-2 / BlueField-3 / ConnectX-4 LX / ConnectX-5 / ConnectX-6 DX LX / ConnectX-7 / ConnectX-8
MLNX_EN 轻量级软件包（已停止支持）/ LTS 长期支持 / EOL 生命周期终止
DKMS Dynamic Kernel Module Support / MOK Machine Owner Key / Secure Boot 安全启动
Kernel Headers 内核头文件 / GCC 编译器 / mod_load_funcs 模块加载函数
openibd InfiniBand 初始化服务 / ofed_uninstall.sh OFED 卸载脚本
mst MST 管理工具 / mlnx-fw-updater 固件更新器 / mst restart 初始化 MST
RS-A1-RS-D 为 OpenFabrics Alliance 归一化版本号 26.04 / 24.10 等
本篇核心命令：
ofed_info / ofed_info -s 查看 OFED 版本 / uname -r 查看内核 / lscpu / lspci -nn 查 HCA
dpkg --list / apt remove --purge 卸载 DEB 系 / rpm -qa / yum -y remove 卸载 RPM 系
/usr/sbin/ofed_uninstall.sh --force 强制卸载 OFED / apt-get autoremove / yum autoremove
dpkg -i 装 repo 包 / rpm -Uvh 装 repo 包 / apt update / apt install -y doca-ofed
/etc/init.d/openibd restart 重启 IB 驱动 / mst restart 初始化 MST / reboot 重启系统
ibstat 读本机端口状态 / ibv_devinfo 读 HCA 详情 / mokutil --import 导入 DKMS 公钥
本篇权威依据：
NVIDIA DOCA《MLNX_OFED to DOCA-OFED Transition Guide》—— 一比一定义、迁移四步、LTS 时间表
NVIDIA DOCA《DOCA Profiles》—— 五个 Profile 的 Purpose / Includes / Recommended for 逐档定义
NVIDIA DOCA《DOCA-Host Installation and Upgrade》—— 卸载、装 repo、装 Profile、openibd restart、mst restart
NVIDIA DOCA《DOCA-Host Installation and DKMS Management Guide》—— DKMS 源码构建、Secure Boot 的 MOK 流程
NVIDIA DOCA《General Support》—— Supported Host OS per DOCA-Host Installation Profile 支持矩阵
OpenFabrics Alliance 官网 ofa-overview 与 ofed-for-linux —— OFED 的定义与代码来源
ArchWiki: InfiniBand 与 ibstat(8) / ibv_devinfo(8) —— 验证输出的字段判读InfiniBandOFEDOpenFabrics AllianceMLNX_OFEDDOCA-OFEDDOCA-Host安装 ProfileDKMSKernel BypassConnectXBlueFieldVPILTS 与 EOLSecure Bootopenibdibstat
★ 学完这一篇你能掌握什么（渐进式路径：1→2→3→4 不可跳跃）
- 第 1 步 · 讲清来历（第一节、第二节、第三节）
• What：OFED 是 OpenFabrics Alliance 归一化维护的 RDMA / 内核旁路软件栈，代码主要取自 github.com/linux-rdma 与 git.kernel.org；MLNX_OFED 是同一软件栈的 Mellanox 品牌发行版；DOCA-OFED 是 DOCA-Host 下的一个 Profile，与 MLNX_OFED 一比一等价
• How：能说清 ConnectX 与 BlueField 过去分别依赖哪套框架，以及这次统一合并了什么、没合并什么
• Why：理解 "一比一替代"这四个字为什么是全篇最重要的一句话——它决定了迁移不需要任何功能取舍论证，只需要看时间表- 第 2 步 · 选对 Profile（第四节）
• What：DOCA-Host 当前共有 doca-all / doca-networking / doca-ofed / doca-roce / doca-host-basic 五个 Profile，其中 doca-roce 与 doca-host-basic 不含 InfiniBand 组件，装了也不能建 IB 子网
• How：能对着"纯 IB 计算节点" / "IB + RoCE 混合" / "有 BlueField" 三种场景分别选出正确 Profile，并说明理由
• Why：理解 "Profile 是子集，不是全量"——官方原文用的词是 a subset of the full DOCA installation，选 Profile 本质是在裁剪安装范围- 第 3 步 · 走完迁移流程（第五节至第十二节）
• What：迁移三段时间点（2024-10 最后独立版 / 2024-10 至 2027-10 LTS / 2027-10 EOL）与四步操作；以及前置检查三条只读命令 ofed_info / uname -r / lspci
• How：能在 DEB 系与 RPM 系两套卸载命令之间正确选择，并把 repo 包、Profile 包、固件更新器三样东西分清楚
• Why：理解 "为什么要先卸载干净再装"——官方安装文档明确要求移除已有 DOCA-Host / MLNX-OFED 包，理由是防止冲突- 第 4 步 · 验证与 IB 专属风险（第十一节、第十二节、第十三节）
• What：ofed_info -s 与 ibstat 两条验证命令的判据；DKMS 源码构建带来的 Secure Boot 信任链问题；opensm 属于默认不装的专有包
• How：能把 ibstat 输出里的 State / Physical state / Base lid / SM lid / Link layer 五个字段对回本系列第八篇的状态机
• Why：理解 "驱动装好不等于 IB 能用"——驱动只解决"主机看得见网卡"，LID 分配与转发表编程仍由 SM 完成★ 阅读前提 & 本篇不涉及的内容
- 前置知识：本系列第八篇《InfiniBand 子网初始化：拓扑发现、LID 分配、路径计算与子网激活》中的端口物理状态与逻辑状态机、ibstat 字段判读；第九篇《SM 监控与拓扑变化》中的 SMA 职责；第十一篇《路由引擎：算法原理、选型对照与 OpenSM 配置验证》中的 opensm 与 opensm.conf。本篇不重复解释这些内容，只在需要时回指
- 信息来源：本篇所有 Profile 定义、迁移步骤、时间表、命令原文与支持矩阵，均引自文末「参考资料」列出的 NVIDIA DOCA 官方文档与 OpenFabrics Alliance 官网；PCI 厂商 ID 引自 Linux 内核 include/linux/pci_ids.h；验证输出格式引自 infiniband-diags 官方 man page 与 ArchWiki
- 本篇不涉及：BlueField 侧 DPU 模式的完整部署流程、GPUDirect RDMA 在 Blackwell + ConnectX-8 上的 Data Direct 补丁集、NVMe-oF 与 NFS-oF 存储包（mlnx-nvme / mlnx-nfsrdma）、VMA / XLIO / libvma 的单独安装路径、集群运维软件的部署
📑 本节目录（按"为什么装 → 装什么 → 怎么装 → 怎么验"的自然顺序）
- 一、OFED 与 OpenFabrics Alliance：这个软件栈是谁在做
- 二、DOCA 是什么：它原本服务谁，为什么最后要和 OFED 合并
- 三、DOCA-OFED 的定位：一比一替代这条红线
- 四、DOCA-Host 安装 Profile：五个档位与 InfiniBand 选型
- 五、迁移时间表：2024 年 10 月到 2027 年 10 月
- 六、迁移四步：下载、卸载、安装、验证
- 七、安装前置检查：三条只读命令
- 八、定位并下载：NVIDIA DOCA 下载页的六次选择
- 九、卸载旧栈：DEB 系与 RPM 系两套命令
- 十、安装：repo 包、Profile 包与固件更新器
- 十一、驱动加载：openibd restart 还是 reboot
- 十二、验证：ofed_info -s 与 ibstat 的判读
- 十三、InfiniBand 视角的三个特有风险点
- 十四、FAQ 高频问答（20 组）
- 十五、Roadmap 后续预告
一、OFED 与 OpenFabrics Alliance：这个软件栈是谁在做
What — 两个必须先分清的名字
本篇的第一件事不是讲安装，而是把三个混在一起的名字拆开。课程口语里它们听起来像同一个东西，实际上是组织 / 发行版 / 品牌三层关系。
- OpenFabrics Alliance（OFA，开放结构联盟）：一个基于开源的组织。官方对自身的定义原文是 —— an open source-based organization that develops, tests, licenses, supports and distributes RDMA/Advanced Networks software and the OpenFabrics Enterprise Distribution。注意这句话里"开发、测试、授权、支持、分发"五个动词并列出现，它说明 OFA 同时是代码维护者与兼容性测试的组织方
- OFED（OpenFabrics Enterprise Distribution，开放结构企业发行版）：OFA 分发的那一套软件。官方对它的定义原文是 —— open-source software for RDMA and kernel bypass applications。这里有两个关键词必须精确理解：RDMA 是协议能力，kernel bypass 是实现手段
- MLNX_OFED：同一套 OFED 软件在 Mellanox / NVIDIA 品牌下的商业发行版，由厂商打包、加固、适配并提供支持
这个三层关系解释了一个常见困惑：OFED 不是某一家公司的私有产品，但 MLNX_OFED 是。前者由联盟归一化维护、面向互通；后者是厂商交付物、面向生产。
1.1 OFED 的代码从哪里来
OFA 官网对 OFED 的来源有一句非常关键的说明：大部分代码取自 github.com/linux-rdma 与 git.kernel.org，在此基础上由厂商加以增强、测试或回合补丁。这句话的工程含义比字面更重要：
| 来源层 | 典型内容 | 谁在维护 |
|---|---|---|
| 上游 Linux 内核 | RDMA 核心子系统、drivers/infiniband/ 下的各厂商驱动 | Linux 内核社区 |
| linux-rdma/rdma-core | libibverbs / librdmacm 用户态库、infiniband-diags 工具集 | rdma-core 项目组 |
| 厂商增强层 | 固件、离线端口配置、性能调优参数、固件更新工具 | 各网卡厂商 |
理解了这条链路，就能解释本系列里反复出现的一个现象：为什么 ibstat、ibv_devinfo 这类工具的行为在不同发行版之间基本一致，但固件版本号和某些厂商私有参数会不同。前者来自 rdma-core 这条共同的上游线，后者属于厂商层。
这一层结论对 IB 部署的直接影响：OFED 的定义里写着支持 InfiniBand、RoCE 与 iWARP 三种传输。也就是说一套 OFED 同时覆盖本系列讨论的 InfiniBand 与以太网上的 RoCE，这正是第四节 Profile 选型必须逐档核对的原因——Profile 裁剪掉的东西，可能正好是 IB 需要的。
1.2 联盟的作用：把"能跑"和"互通"分开验证
OFA 除了维护代码，还做一件对生产环境很关键的事：与 UNH-IOL（新罕布什尔大学互操作实验室）合作开展互通测试。官方描述的机制是：软件、服务器、存储与网络厂商、OEM 与系统集成商，只要其产品支持 OFED，就参与这个透明流程；通过测试的产品被授予使用 OFA Interoperability 商标的许可，且测试结果对公众公开。每年安排两轮 Debug 事件与两轮 Logo 事件。
设计意图：把兼容性风险从"你的现场"前移到"厂商的实验室"
互通测试的机制设计有一个值得注意的点：Debug 事件用最新的候选版本来测，Logo 事件则用正式版本来固化结果。前者是"你将要装的版本现在能不能互通"，后者是"这个已经发布的组合被证明能互通"。对现场部署的意义是：选型时应优先采用已通过 Logo 事件的硬件 + 固件 + OFED 版本组合，而不是各自取最新。这条原则在本次迁移中同样适用——不要为了"最新"而偏离已验证组合。
本节关键记忆：1 个组织 + 1 个发行版 + 1 个厂商版 + 2 条代码来源
- OFA：开源组织，职责是开发、测试、授权、支持、分发五件事
- OFED：面向 RDMA 与内核旁路应用的开源软件，覆盖 InfiniBand / RoCE / iWARP
- MLNX_OFED：OFED 的厂商商业发行版，不是另一个软件栈
- 代码来源：主要取自 github.com/linux-rdma 与 git.kernel.org，厂商在其上做增强与回合补丁
- 兼容性机制：与 UNH-IOL 合作互通测试，通过者获 OFA 商标许可，结果公开可查
二、DOCA 是什么：它原本服务谁，为什么最后要和 OFED 合并
What — DOCA 的全称与原始定位
课程转写把 DOCA 反复听成"doke" / "doc a"，正式名称是 DOCA（Data Center On-Chip Architecture，数据中心片上架构）。理解 DOCA 的关键不在名字，而在它要解决的问题：NVIDIA 有两类完全不同的主机网卡，但过去用两套完全不同的软件框架来支持它们。
- ConnectX 系列：智能网卡（SmartNIC），形态是 PCIe 插卡或 OCP 插槽，过去依赖 MLNX_OFED 框架
- BlueField 系列：DPU / SuperNIC，形态是把网络、存储与计算卸载做进一颗芯片，过去依赖 DOCA 框架
这个割裂带来的是真实的工程成本：同一个机房里有 ConnectX 计算节点和 BlueField 存储节点时，主机侧的安装方式、工具集与支持路径是两套。DOCA 最初就是为 BlueField 而建的，OFED 那时是 ConnectX 的标准答案。
2.1 合并前后的对照
官方文档对这次统一的表述很直接：ConnectX 与 BlueField 现在统一到单一框架 DOCA 之下，DOCA-OFED 被并入 DOCA-Host 这个统一的软件解决方案。合并的关键结构可以画成一张图：
===== 合并前：两套框架，两套主机软件栈 =====
ConnectX 智能网卡 ──────> MLNX_OFED 框架
(MCX-4 / 5 / 6 / 7) 内核驱动 / libibverbs / librdmacm / infiniband-diags
│
└─ 维护节奏：由 Mellanox 品牌单独发布
BlueField DPU ─────────> DOCA 框架
(BF-2 / BF-3) DOCA Core / OVS / Flow / DPDK 等
│
└─ 维护节奏：由 DOCA 项目单独发布
===== 合并后：一套框架，多个 Profile =====
┌──────────────────────────────────────┐
│ DOCA-Host 统一主机软件包 │
│ (同时支持 BlueField 与 ConnectX) │
└──────────────────────────────────────┘
│
┌───────────┬───────────────┼───────────────┬───────────────┐
▼ ▼ ▼ ▼ ▼
doca-all doca-networking doca-ofed doca-roce doca-host-basic
完整套件 仅网络相关 等价 MLNX_OFED 仅 RoCE 极简以太网
│ │ │ │ │
└───────────┴───────┬───────┘ │ │
│ │ │
┌────────────┴────────────┐ │ │
│ ConnectX 与 BlueField │ │ │
│ 共用同一套安装与工具链 │ │ │
└─────────────────────────┘ │ │
└── 只有以太网 │
与 RoCE │
│
✗ 不含 IB 组件 ─┘这张图里最要紧的一条线是底部那两个 Profile。官方对 doca-roce 的描述是 includes only Ethernet and RoCE drivers, without IB specific components——它是 DOCA_OFED 的子集，用来接替更早的 MLNX_EN 轻量级软件包。换句话说，选 doca-roce 装出来的主机，是建不了 InfiniBand 子网的。第四节会专门展开这一条。
2.2 DOCA 架构的定义：它划的是交互的界线
课程给出了一条关于 DOCA 架构的定义：DOCA 架构定义了交互的方式，并在不同协议、驱动与内核组件之间建立共同语言，以建立 RDMA 连接。这条定义解释了"统一"二字的准确含义——统一的是接口层，不是把两个网络世界合成一个。
设计意图：统一的粒度是"接口与工具链"，不是"抹平设备差异"
把 ConnectX 与 BlueField 统一到 DOCA 之下，官方给出的收益表述是：为高性能计算站点与企业数据中心提供灵活性与投资保护。这两条收益各自有明确的技术对应：
- 灵活性：同一套安装包按 Profile 裁剪，ConnectX 与 BlueField 可以共存于同一主机软件栈，扩容时不必换软件体系
- 投资保护：DOCA-OFED 与 MLNX_OFED 等价，已有的 MLNX_OFED 部署可以平移，不需要为软件变化重做验证
需要留意的是官方文档中反复出现的一句限定：DOCA 的功能受具体设备能力限制，并举例说明 ConnectX 设备无法使用 DPA 这类 DOCA 库，即便主机装了 doca-all。也就是说Profile 只决定"装什么"，设备能力才决定"能用什么"，这是两个独立的约束维度。
本节关键记忆：2 类设备 + 1 次统一 + 1 个限定条件
- 合并前：ConnectX 走 MLNX_OFED 框架，BlueField 走 DOCA 框架，两套栈两套维护节奏
- 合并后：统一到 DOCA 单一框架，DOCA-OFED 并入 DOCA-Host 统一主机软件包
- DOCA 架构定义：定义交互方式，在不同协议、驱动与内核组件之间建立共同语言，以建立 RDMA 连接
- 官方给出的收益：灵活性（同一软件栈共存两类设备）+ 投资保护（等价平移）
- 1 个限定条件：Profile 决定装什么，设备能力决定能用什么；ConnectX 装了 doca-all 也用不了 DPA
三、DOCA-OFED 的定位：一比一替代这条红线
What — 官方对 DOCA-OFED 的两句定义
这一节只有两段官方原文，但整篇的决策逻辑都压在里面：
- 等价性：DOCA-OFED is an equivalent package of MLNX_OFED, providing the same functionality as MLNX_OFED and including the same kernel drivers, user space libraries, and management tools。并且明确补充支持与 MLNX_OFED 相同的操作系统与应用程序
- 替代性：DOCA-OFED is a 1-to-1 substitute for MLNX_OFED. All customers using MLNX_OFED on their host-server should install DOCA-OFED instead
课程把这两段话讲成了"用户体验完全相同"和"一对一替代"，表述是准确的。但它们在工程上意味着三件很强的事，值得逐条拆开。
3.1 "一比一"到底省掉了哪些论证
第一，它省掉了"功能差异对照表"。迁移软件时，标准做法是先做一份新版本与旧版本的功能对照，逐项确认没有回退，再决定是否升级。这份对照表本身有维护成本，且往往滞后于两个版本的发布节奏。而"equivalent package"这个表述直接把它消解了——官方文档本身就是那份对照表，结论是无差异。
第二，它省掉了"要不要重新做一遍验证"。如果两个栈等价，那么在 MLNX_OFED 上跑通的验证项，在 DOCA-OFED 上应当同样成立。实践含义是：迁移前已有的验证报告可以作为迁移后的起点，而不是要求从头再来一遍。这在有审计要求的行业里是实打实的成本节约。
第三，它把决策变量压缩到只剩一个。官方明确写了"在 MLNX_OFED 最后一次发布之后，不会再向 MLNX_OFED 添加新功能，所有新功能只会以 DOCA-OFED 的一部分提供"。这句话给出了一个确定性的分界线：MLNX_OFED 只会越来越旧，DOCA-OFED 只会越来越新。于是"要不要迁"不再取决于技术风险，只取决于 LTS 窗口还剩多久。
| 决策维度 | 若为"新功能"叠加 | 实际为"一比一替代" |
|---|---|---|
| 功能差异 | 需逐项核对，做功能对照表 | 官方声明等价，无需对照 |
| 回退风险 | 需评估依赖新特性的代码路径 | 不存在特性依赖，代码无需改动 |
| 验证成本 | 需完整重跑验证 | 已有验证可作起点 |
| 决策变量 | 技术风险 + 支持周期 | 仅剩支持周期 |
但有一条必须同时说清楚，否则容易把"一比一"读成"零成本"：一比一指的是"提供的功能等价"，不是"装的过程零操作"。官方给出的流程里包含先卸载既有 MLNX_OFED这一明确要求——说明安装过程本身有真实动作，第六节至第十节讲的就是这些动作。
3.2 "不增加新功能"这一句的分量
课程在总结部分特意点出了这一条：MLNX_OFED 的最后一个独立版本发布之后，不再有新功能加入，所有新功能只会作为 DOCA-OFED 的一部分提供。这一句在时间轴上的含义是：MLNX_OFED 进入了一个只减不增的状态。
对已经在 MLNX_OFED LTS 上稳定运行的生产环境的实际含义
LTS 期间会继续收到关键缺陷修复与安全更新，这意味着"不迁移"在短期内是安全的。但"不增加新功能"这四个字有一个不易察觉的后果：如果你的业务后续需要新硬件特性——比如新一代网卡带来的新 offload、新传输类型、新固件特性——那么这些能力在 MLNX_OFED 上永远不会出现，只能等 EOL 后切到 DOCA-OFED。这意味着不迁移的真实代价不是当下的稳定性风险，而是未来能力扩展时的被动局面。
本节关键记忆：2 句官方原文 + 1 条分界线 + 1 个提醒
- 等价性：DOCA-OFED 是 MLNX_OFED 的等价包，同样的内核驱动、同样的用户态库、同样的管理工具，支持相同的 OS 与应用
- 替代性：1-to-1 substitute，官方要求所有 MLNX_OFED 用户改装 DOCA-OFED
- 功能边界：DOCA-OFED 不包含任何其他 DOCA 组件，这是它与 doca-networking / doca-all 的根本区别
- 1 条分界线：MLNX_OFED 只减不增，新功能只会进 DOCA-OFED
- 1 个提醒："等价"指功能等价，不等于安装零操作——官方流程明确要求先卸载
四、DOCA-Host 安装 Profile：五个档位与 InfiniBand 选型
What — Profile 是什么，为什么要有它
官方对 Profile 的定义有两句关键表述：DOCA-Host profiles are validated and tested installation packages（经过验证与测试的安装包），以及 DOCA-Host Installation Profiles, which are a subset of the full DOCA installation（是完整 DOCA 安装的子集）。
这两句话合起来定义了 Profile 的性质：它是一个被验证过的子集，不是随便拼的安装组合。这带来一个实际好处——选 Profile 不需要你自己判断依赖关系，NVIDIA 已经把"这组包在一起是能用的"这件事验证过了。
这里要先纠正课程的一处过时表述：课程说"DOCA-Host 有四个安装 Profile"，这句话在录制时成立，但当前官方文档已列出五个。下表按当前官方文档全量列出，并在最后一列标明课程口径的适用范围。
4.1 五个 Profile 的官方定义逐档拆解
下表严格按官方《DOCA Profiles》的 Purpose / Includes / Recommended for 三栏整理。其中 Includes 一栏是本节的重点——判断一个 Profile 能不能用于 InfiniBand，只看这一栏就够。
| Profile | Purpose（官方原文要义） | Includes（包含内容） | 含 IB 组件？ |
|---|---|---|---|
| doca-all | 安装完整 DOCA 套件，含所有库、驱动与工具 | 全部 DOCA 库与驱动、MLNX_OFED、DOCA Core、MLNX-DPDK、OVS-DOCA、DOCA Flow | 是 |
| doca-networking | 仅网络相关的安装，不承担完整 DOCA 库开销 | MLNX_OFED、DOCA Core、DOCA-PCC、OVS-DOCA、DOCA Flow、DOCA Perftest | 是 |
| doca-ofed | 与 MLNX_OFED 等价的仅驱动安装 | MLNX_OFED 驱动与工具 | 是 |
| doca-roce | 轻量级 RDMA over Ethernet 功能 | rdma-core、ofed-scripts、mlnx-tools、mlnx-ofa_kernel、perftest | 否 |
| doca-host-basic | 轻量级纯以太网功能 | rdma-core、mlnx-tools、mlnx-ofa_kernel、perftest、mlnx-ethtool、mlnx-iproute2 | 否 |
这张表最重要的一行是 doca-roce 与 doca-host-basic
官方对 doca-roce 的定位写得很明确：它只包含以太网与 RoCE 驱动，不含 IB 专用组件，并且它是 DOCA_OFED 的子集，存在的目的是给那些只要 RoCE 能力、想要小安装包的用户一个选项（它接替的是更早的 MLNX_EN）。doca-host-basic 官方描述为"类似 doca-roce 但不含 MFT 与 FW-Updater 的基础以太网功能"，同样不含 IB。
对本系列读者的直接结论：如果这台主机要跑 InfiniBand，doca-roce 与 doca-host-basic 都不在候选范围内，可选项只有 doca-ofed / doca-networking / doca-all 三个。第十九、二十两问专门讨论这个误选问题。
4.2 按设备类型的官方推荐
官方给出的推荐是分设备类型的，这点很关键——同一个 Profile 对 ConnectX 主机与 BlueField 主机的推荐结论并不相同：
| 目标能力 | BlueField 设备 | ConnectX 设备 |
|---|---|---|
| 完整能力 | 推荐 doca-all | 有 BlueField 与 ConnectX 混合部署，或将来可能引入时，推荐 doca-all |
| 最小网络安装包 | 用 doca-networking | 推荐 doca-networking |
| 类 MLNX_OFED 安装 | 用 doca-ofed（不含额外 DOCA 功能） | 用 doca-ofed（不含额外 DOCA 功能） |
| 只要 RoCE | 装 doca-roce | 装 doca-roce |
| 只要基础以太网，不要 MFT 与 FW-Updater | doca-host-basic | doca-host-basic |
官方文档里的一条补充说明，容易被略过
在 doca-all 一档，官方特别注明：某些组件在默认包安装之后可能仍需手动安装（原文为 Some components may require additional manual installation after the default package is installed）。也就是说"装了 doca-all 就等于全部可用"这个推论并不成立，装完仍需按具体用例确认组件是否齐备。
4.3 支持的设备清单
官方列出的、全部 Profile 共同支持的硬件为：BlueField-3、BlueField-2、ConnectX-8、ConnectX-7、ConnectX-6 DX / LX / standard、ConnectX-5、ConnectX-4 LX。这七项构成了部署前的硬性前置条件——如果卡不在这个清单里，装 Profile 解决不了问题。
把 Profile 理解成"安装范围的裁剪配置"还不够完整。看官方那句 DOCA-Host profiles are validated and tested installation packages，以及它紧跟的那句 Each DOCA-Host profile is supported on a subset of operating systems，可以看出 Profile 实际绑定的是一个二维矩阵：
| Profile 轴 | OS / 架构轴 | |
|---|---|---|
| 取值 | 5 个 Profile 之一 | 发行版 + 主版本 + 内核 + CPU 架构 |
| 来源 | 官方按"是否需要 DOCA 库"划分 | 官方维护的 Supported Host OS per DOCA-Host Installation Profile 表 |
| 失败形态 | 装错 Profile → 缺组件，功能不可用 | 装错组合 → 内核模块装不上或不可用 |
这两条轴的失败形态完全不同，排查时也不该混为一谈。缺组件表现为"命令找不到""库链接失败"，OS 不支持表现为"DKMS 编译报错"或"模块无法加载"。第十节会展开 DKMS 这条线，因为它解释了为什么内核头文件与编译器版本是硬性前置条件。
官方在这两点上有一句很重要的声明，与本篇第三节的"一比一"形成有趣的对照：官方明确提醒，NVIDIA 不再为次要 OS 版本发布仓库，必须使用按主版本发布的仓库，让 DKMS 自行处理内核差异。翻译成可操作的结论是：RHEL 9.4 与 RHEL 9.6 都用 RHEL 9 仓库，不要去找 9.4 专用仓库。这与"一比一替代"是两种不同的简化——前者减少用户的版本选择负担，后者减少迁移的功能风险。
本节关键记忆：5 个 Profile + 3 个可用于 IB + 7 款支持设备 + 2 条独立轴
- 5 个 Profile：doca-all / doca-networking / doca-ofed / doca-roce / doca-host-basic（课程录制时为前四个）
- 可用于 IB 的 3 个：doca-all / doca-networking / doca-ofed
- 不含 IB 的 2 个：doca-roce（只有以太网与 RoCE 驱动）/ doca-host-basic（纯以太网）
- Profile 本质：经验证与测试的子集，不是随意拼装的组合
- 7 款支持设备：BF-3 / BF-2 / CX-8 / CX-7 / CX-6 DX LX / CX-5 / CX-4 LX
- 2 条独立约束轴：Profile 决定装什么，OS 与设备能力决定能用什么
五、迁移时间表：2024 年 10 月到 2027 年 10 月
What — 三个时间点，两种支持状态
课程把迁移时间表讲成了三个节点，官方原文的表述如下。这一节之所以重要，是因为它把"要不要迁"这个问题从技术判断转成了日程判断。
5.1 三个节点
| 时间 | 状态 | 具体含义 |
|---|---|---|
| 2024 年 10 月 | MLNX_OFED 最后一个独立版本发布 | 此版本之后不再获得新功能或增强的支持；官方鼓励尽快切换，以持续获得新特性 |
| 2024 年 10 月 – 2027 年 10 月 | LTS 长期支持期（3 年） | 最后一个独立版本继续获得关键缺陷修复与安全更新，作为长期支持计划的一部分 |
| 2027 年 10 月 | MLNX_OFED 生命周期终止（EOL） | NVIDIA 不再提供任何支持或更新；官方强烈建议在此日期前完成切换，以避免兼容性与安全问题 |
课程对 LTS 期内的支持范围表述是关键缺陷修复与安全更新，官方原文为 critical bug fixes and security updates，完全一致。这里有一个常被误读的点需要点明：LTS 期间的支持是有限范围的，不包含新功能。"还在收到更新"与"还在演进"是两件事。
5.2 怎么用这张表做排期
时间表本身只给结论，真正有用的是把它转成可执行的排期规则。下面三条是按官方表述直接推导出的判断依据，不含任何推测成分。
- 规则一：把"新特性需求"当成迁移的硬触发条件
MLNX_OFED 不再新增功能，因此任何依赖新特性的需求在 MLNX_OFED 上都不可满足。判断式是：这个需求是否能在当前 MLNX_OFED 版本上直接满足？能，则不急；不能，则迁移时间点由需求上线时间倒推，而不是由 EOL 日期决定。
- 规则二：把"安全合规"当成另一个独立触发条件
LTS 期内有安全更新，但 EOL 之后连安全更新都没有了。如果所在环境有外部安全基线要求（等保、PCI DSS、内部漏洞管理周期等），那么 EOL 日期不是"可以考虑迁"的节点，而是合规失效的节点。
- 规则三：把 EOL 前留出的窗口按验证成本倒推
官方只说了"在此日期前"切换，没说提前多久。但从第三节"一比一替代"的推导出发，迁移本身的技术风险接近于零，剩下的成本集中在验证与变更窗口，因此实际窗口应按验证项数量 × 单项耗时 + 回退预案时间倒推，而不是按习惯留出几个月。
一个可复用的排期方法
把第三节与第五节合起来看，可以得到一个比"距 EOL 还有多久"更有用的判据：先算清楚现有环境有多少个验证项——其中凡是只涉及驱动加载、工具可用性、端口状态的，都属于"一比一"覆盖的范围，可以快速批量通过；凡是涉及子网管理、性能基线、业务压测的，都需要在目标环境重跑一次。这两类的比例，决定了你需要多长的窗口。第十三节与 FAQ 第十五问会再回到这个话题。
本节关键记忆：3 个节点 + 1 条分界线 + 3 条排期规则
- 2024-10 最后一个独立版本 → 此后无新功能
- 2024-10 → 2027-10 LTS 期 → 仅关键缺陷修复与安全更新，不含新功能
- 2027-10 EOL → 无任何支持与更新，官方强烈建议在此前完成切换
- 1 条分界线："还在收到更新" ≠ "还在演进"，LTS 期间功能冻结
- 3 条排期规则：新特性需求是硬触发 / 安全合规是独立触发 / 窗口按验证成本倒推
六、迁移四步：下载、卸载、安装、验证
What — 官方给出的四步
官方《MLNX_OFED to DOCA-OFED Transition Guide》给出的切换步骤是四步，课程的表述与之一致：
- 下载：从 NVIDIA 官网或公共仓库下载最新的 DOCA-Host 包
- 卸载：从系统中卸载现有的 MLNX_OFED 包
- 安装：用标准的 Linux 包管理器在主机服务器上安装 DOCA-OFED 包
- 验证：重启系统并确认 DOCA-OFED 组件工作正常
课程把第四步讲成了"重启 DOCA-OFED 驱动并验证组件工作正常"，语义方向一致，但动作不同。这处差异值得单独澄清，因为选错动作会有实际后果。
6.1 第四步的两种官方表述
两个版本的官方文档写法不同，需要按场景选择
课程录制时的口径与当前文档存在一处可观察到的差异，两边都出自 NVIDIA 官方文档：
- 迁移指南的表述是 Reboot your system and verify that the DOCA-OFED components are working properly——明确说重启系统后验证
- 安装与升级页的表述是加载驱动，命令为 /etc/init.d/openibd restart，随后再执行 mst restart
课程讲的是"重启驱动"，对应的是第二条。两条并不矛盾——它们回答的是不同问题：openibd restart 解决"新模块还没加载"，reboot 解决"整个系统还停留在旧状态"。第十一节会把这两者的适用边界讲清楚，这里先给结论：首次安装按迁移指南走 reboot 最稳妥；日常只重载驱动用 openibd restart；升级场景优先 reboot。
6.2 两种安装通道
课程第八节提到下载时要选择 local（本地）或 online（在线）两种安装器类型，选完会把你导向 NVIDIA 官网或 DOCA 公共仓库。这一点与官方文档完全对应——《DOCA-Host Installation and Upgrade》开篇就把安装方式分为两张表：安装用 DOCA 本地 repo 包，升级用 DOCA 在线仓库。
两者的差别在实操层面很具体，本地 repo 包只解决"把包送进本地仓库"，真正的安装仍然由包管理器完成。下面是一次完整的在线仓库安装示例，取自官方迁移指南：
# 以 RHEL 系为例：从 DOCA 在线仓库安装 doca-ofed
# echo "[doca]
# name=DOCA Online Repo
# baseurl=https://linux.mellanox.com/public/repo/doca/2.7.0/rhel9.4/x86_64/
# enabled=1
# gpgcheck=0" > /etc/yum.repos.d/doca.repo
# sudo dnf clean all
# sudo dnf -y install doca-ofed注意这段示例里的三处细节，它们不是格式问题而是可操作信息：
- 仓库 URL 里有版本号路径（示例为 doca/2.7.0/rhel9.4/x86_64/）——DOCA 版本、OS 版本、架构三段都在路径里
- 有 dnf clean all 这一步——清缓存再装，避免用到旧元数据
- 安装目标是 doca-ofed 这个 Profile 名，不是某个具体驱动包名——这正是 Profile 作为"经验证的子集"的价值体现
本节关键记忆：4 步 + 2 条通道 + 3 处细节
- 4 步：下载 → 卸载 → 安装 → 验证；顺序不可颠倒，官方要求先卸载以避免冲突
- 2 条通道：安装用本地 repo 包，升级用在线仓库
- 第 4 步的两种表述：迁移指南说 reboot，安装页说 /etc/init.d/openibd restart → 见第十一节
- 3 处细节：仓库 URL 含 版本/OS/架构 三段路径；装前 dnf clean all；装的是 Profile 名而非驱动包名
七、安装前置检查：三条只读命令
What — 为什么迁移前必须先做只读检查
课程把安装前检查讲成三件事：① 当前是否已装 OFED、是什么版本；② 主机内核与操作系统版本；③ 是否装了 HCA。这三件事的共同点是全部是只读操作，不修改系统状态，因此在动手卸载之前就可以全部做完并归档。
它的作用有两层：决定下载哪个包（需要 OS 版本与架构），以及区分"装完不通"是环境问题还是迁移问题（需要安装前的 HCA 存在性基线）。
7.1 命令一：ofed_info — 判断起点状态
课程给出的方式是运行 ofed_info 查看当前 OFED 版本，并给出一条明确的分支判断：如果已经是最新版本，就不需要升级；如果根本没有安装 OFED，这次就是一次全新安装（clean install）。
这里要把 ofed_info 的两个用法分清，它们输出形态不同：
| 用法 | 输出形态 | 适用场景 |
|---|---|---|
| ofed_info | 完整清单：首行是发行版版本号，其后逐行列出 clusterkit、dpcp、ibdump、rdma-core、ucx 等各组件的源码包路径与版本 | 需要排查某个具体组件版本时 |
| ofed_info -s | 仅首行的发行版版本号，例如形如 MLNX_OFED_LINUX-23.07-0.5.1.2 | 只需要判断"装没装、什么版本"，脚本化判断的首选 |
版本号该怎么读
MLNX_OFED_LINUX-23.07-0.5.1.2 这样一串数字里，第一段 23.07 是年月（2023 年 7 月），后面几段是构建号。读版本号只需要看第一段就能判断新旧，这也是为什么"是不是最新版本"这个问题用首行就能回答。第十二节的验证环节仍然用 ofed_info -s，因为要回答的是同一个问题。
7.2 命令二：uname 与发行版信息 — 决定下载哪个包
课程指出这一步要收集主机内核与操作系统版本，因为选对 DOCA-OFED 包必须用它，并给出示例环境：Ubuntu 22.04，x86_64 架构。
官方支持矩阵正是按这个口径组织的。《General Support》给出的表列名是 OS / OS Version / Tested Kernel / Arch，再横切各个 Profile。以当前文档为例，Ubuntu 22.04 一行的结构如下（Arch 与 Profile 列为示意，完整表以官方为准）：
官方支持矩阵的列结构（Supported Host OS per DOCA-Host Installation Profile）
OS | OS Version | Tested Kernel | Arch | doca-ofed | doca-networking | doca-all
------+-------------+------------------+----------+-----------+-----------------+---------
Ubuntu| 22.04.x | 5.15.0, 6.8-HWE | aarch64 | ✓ | ✓ | ✓
| | | x86 | ✓ | ✓ | ✓
| | | ppc64le | ✓ | ✗ | ✗
------+-------------+------------------+----------+-----------+-----------------+---------
读表要点：
① 每行是一个 (发行版, 版本, 内核, 架构) 四元组，不是单纯按发行版
② 同一行内各 Profile 的支持状态可能不同 —— ppc64le 上 doca-ofed 支持，
doca-networking 与 doca-all 不支持
③ 官方注明"仅支持 DOCA 本地 repo 包所使用的下列通用内核版本"
④ 次要 OS 小版本不再单独出仓库，一律用主版本仓库，由 DKMS 处理内核差异这张表里最容易被跳过的一列是 Arch
课程示例给的是 x86_64，但矩阵里 Arch 是独立一列，且同一发行版不同架构的 Profile 支持状态不同。这不是理论风险——在 aarch64 平台（如 Grace 服务器）与 ppc64le 平台上做 IB 部署时，装错 Profile 会直接导致目标 Profile 不可用。
7.3 命令三：lspci — 确认 HCA 在位
课程给出的是运行 lspci 并grep Mellanox，示例输出显示系统上装的是一张 ConnectX-6 HCA。
这条命令为什么能识别 InfiniBand 网卡？可以从内核源码得到确认。Linux 内核 include/linux/pci_ids.h 中定义了 PCI_VENDOR_ID_MELLANOX，其值为 0x15b3。因此有两个等价写法：
# 写法一：按厂商名过滤（课程用法，可读性最好）
lspci | grep -i mellanox
# 写法二：按 PCI 厂商 ID 过滤（脚本友好，ID 定义见 include/linux/pci_ids.h）
lspci -d 15b3:两种写法抓到的设备范围略有差别，值得说清楚。原因是 ConnectX 的 VPI 卡在 PCI 总线上会暴露两个功能，一个函数是 InfiniBand 控制器，另一个是以太网控制器。官方支持页给出的实测输出正是这个形态：
# 一张 ConnectX-4 双口卡在总线上的两条记录（官方支持页实测输出形态）
$ lspci | grep -i mellanox
05:00.0 Infiniband controller: Mellanox Technologies MT27700 Family [ConnectX-4]
05:00.1 Infiniband controller: Mellanox Technologies MT27700 Family [ConnectX-4]注意这两条都显示为 Infiniband controller，因为它们是两个物理端口，而不是一张卡的两种协议面。对比另一份实测输出，可以看到同一张 VPI 卡在协议面拆分时的形态：
# 同一张 VPI 卡，InfiniBand 面在 82:00.0，以太网面在 82:00.1
$ lspci -d 0x15b3:0x1013
82:00.0 Infiniband controller: Mellanox Technologies MT27700 Family [ConnectX-4]
82:00.1 Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]为什么这一步对 IB 部署特别重要
本系列第八篇讲过，SM 分配 LID 是按端口粒度的，双端口 HCA 会拿到两个不同的 LID。而这里 lspci 输出的条数恰好对应物理端口数。也就是说，这张命令的输出条数本身就是子网初始化时"应该有几个 HCA 端口"的基线——迁移后如果 ibstat 列出的端口数与安装前 lspci 的条数不一致，说明驱动侧出了问题，而不是网络侧。
本节关键记忆：3 条只读命令 + 2 种 ofed_info 用法 + 1 个厂商 ID + 1 组基线
- 3 条只读命令：ofed_info（起点状态）/ uname -r + 发行版（选包）/ lspci（HCA 在位）
- 2 种用法：ofed_info 出完整组件清单，ofed_info -s 只出首行版本号
- 版本号读法：第一段 23.07 即年月，看首段即可判新旧
- 1 个厂商 ID：PCI_VENDOR_ID_MELLANOX = 0x15b3，定义于 include/linux/pci_ids.h
- 1 组基线：lspci 的输出条数 = 物理端口数，与 SM 按端口分配 LID 的粒度一致
八、定位并下载：NVIDIA DOCA 下载页的六次选择
What — 课程描述的选择序列
课程把下载流程描述成一串顺序选择，这与官方文档的组织方式一致：DOCA 的组件按"设备类型 → 组件 → 操作系统 → 架构 → 发行版 → 版本 → 安装器类型"的维度组织，页面上以按钮形式呈现，每选一次收窄一次范围。
课程给出的示例路径是：主机服务器 → DOCA-OFED → Linux → 主机架构（示例为 x86_64）→ doca-ofed（Profile）→ Ubuntu → 22.04 → 安装器类型（local 或 online）。
8.1 六次选择各自的判据
| # | 选择项 | 判据来源 | 选错的后果 |
|---|---|---|---|
| 1 | 设备类型（主机服务器 / BlueField） | 本机装的是什么卡。课程选"主机服务器"，对应 ConnectX 主机 | 选 BlueField 会拿到 DPU 侧组件，主机侧装不上 |
| 2 | 组件 / 产品线 | 要装的是 OFED 组件还是 DOCA 组件 | 取到非 OFED 组件 |
| 3 | 操作系统（Linux） | 本篇场景即 Linux | 取到非 Linux 包 |
| 4 | CPU 架构 | lspci 之外还需 lscpu 确认；示例为 x86_64 | 架构不符，包无法安装 |
| 5 | 发行版与版本 | ofed_info -s 无法提供，需 cat /etc/os-release；示例为 Ubuntu 22.04 | 取到不匹配的发行版包 |
| 6 | 安装器类型（local / online） | local 用于离线环境，online 需要能访问公共仓库 | 离线环境选 online → 安装时拉取失败 |
课程在第六步之后补充了一句：选择安装器类型会把你导向 NVIDIA 官网或 DOCA 公共仓库去下载，并且下载并使用 DOCA 框架即表示同意 DOCA 最终用户许可协议。这一条是合规相关的实际约束，迁移排期时应提前确认。
8.2 一步被课程略过、但必须知道的事实
课程说"下载 doca-ofed 的 deb 包"，但 DOCA 实际下载的是 repo 包，不是 Profile 包
这是本节最容易导致实操失败的一点。官方安装流程的产物是 DOCA-Host repo 包（DEB 系是一个 .deb，RPM 系是一个 .rpm），它里面装的是仓库配置，不是驱动本身。真正的 Profile 包（doca-ofed）是装好 repo 之后由包管理器从仓库里拉的。课程转写里"下载 doca-ofed 的 deb 包"这个说法，把两样东西合成了一样。
官方给出的离线安装示例把这两步分得很清楚——先 rpm -i repo 包，再 dnf install Profile：
# 官方迁移指南给出的离线 repo 安装示例（RHEL 系）
$ wget https://www.mellanox.com/downloads/DOCA/DOCA_v2.7.0/host/doca-host-2.7.0-209000_24.04_rhel94.x86_64.rpm
$ sudo rpm -i doca-host-2.7.0-209000_24.04_rhel94.x86_64.rpm
$ sudo dnf clean all
$ sudo dnf -y install doca-ofed把这条命令拆开读，文件名里其实已经把四个选择维度都编码进去了：
文件名各段的含义（取自上面这条官方示例命令）
doca-host-2.7.0-209000_24.04_rhel94.x86_64.rpm
│ │ │ │ │ │ │
│ │ │ │ │ │ └── .rpm = RPM 系
│ │ │ │ │ └───────── x86_64 = 第 4 次选择：架构
│ │ │ │ └──────────────── rhel94 = 第 5 次选择：发行版+版本
│ │ │ └─────────────────────── 24.04 = 适配目标 OS
│ │ └─────────────────────────────── 209000 = 构建号
│ └────────────────────────────────────── 2.7.0 = DOCA 版本
└─────────────────────────────────────────────── doca-host = 这是 repo 包，不是 Profile 包
关键结论：产物是 repo 包；doca-ofed 这个 Profile 要另外用包管理器装本节关键记忆：6 次选择 + 1 处必须纠正 + 1 个文件名读法
- 6 次选择：设备类型 → 组件 → 操作系统 → 架构 → 发行版与版本 → 安装器类型
- 第 6 步的合规含义：下载并使用 DOCA 即表示同意 DOCA 最终用户许可协议
- 1 处必须纠正：下载的是 repo 包，不是 doca-ofed Profile 包；Profile 由包管理器从仓库拉取
- 文件名即选择结果：doca-host-2.7.0-209000_24.04_rhel94.x86_64.rpm 里编码了版本、目标 OS、发行版、架构、包格式
九、卸载旧栈：DEB 系与 RPM 系两套命令
What — 为什么要先卸载，而且要卸载干净
官方在两处都给出了明确要求。迁移指南的流程第 2 步是"卸载系统中现有的 MLNX_OFED 包"；DKMS 管理指南的安装流程第 1 步写得更直接：如果当前已安装 DOCA-Host 或 MLNX-OFED 包，必须先移除以避免冲突。
课程在这一节讲到了要点：如果主机上装着较旧的 MLNX_OFED 或 DOCA-OFED 版本，必须先卸载再装新版本，并给出了 DEB 系主机的卸载示例。这里"较旧版本"三个字很关键——课程强调的是版本冲突，这比"有就必须卸"更贴近实际：全新安装的主机不需要卸载，但装了旧版就必须先卸。
9.1 官方卸载命令原文
官方《DOCA-Host Installation and Upgrade》给出的完整卸载流程，DEB 系与 RPM 系各一条命令链，不是一条命令而是四步：
# ===== DEB 系（Debian / Ubuntu）=====
# 第 1 步：遍历已装的 doca / flexio / dpa-* / dpdk-community 包并 purge
for f in $( dpkg --list | grep -E 'doca|flexio|dpa-gdbserver|dpa-stats|dpa-resource-mgmt|dpaeumgmt|dpdk-community' | awk '{print $2}' ); do echo $f ; sudo apt remove --purge $f -y ; done
# 第 2 步：跑 OFED 官方卸载脚本，--force 跳过确认
sudo /usr/sbin/ofed_uninstall.sh --force
# 第 3 步：清理无依赖孤儿包
sudo apt-get autoremove# ===== RPM 系（RHEL / Rocky / SLES）=====
# 第 1 步：遍历已装的 doca 包并 remove
for f in $(rpm -qa | grep -i doca ) ; do sudo yum -y remove $f; done
# 第 2 步：跑 OFED 官方卸载脚本
sudo /usr/sbin/ofed_uninstall.sh --force
# 第 3 步：清理孤儿包
sudo yum autoremove
# 第 4 步：重建本地缓存（RPM 系多这一步，DEB 系没有）
sudo yum makecache这条命令值得单独想一下：一个卸载动作要分成"包管理器删包"与"独立脚本删文件"两段执行，而这两段针对的对象并不相同。包管理器删的是包数据库里有记录的组件；ofed_uninstall.sh 删的是包管理器管不到的部分——具体是 /usr/sbin/ 下的脚本本身、模块加载配置、以及 openibd 服务留下的文件。
这个分裂有明确的技术成因：OFED 的历史包袱与厂商增强层不属于任何单一发行版的包。OFA 官网明确说明 OFED 的代码主要取自 github.com/linux-rdma 与 git.kernel.org，厂商在此之上做增强与回合补丁。这些增强部分没有上游发行版愿意接管，只能由厂商自己的脚本清理。
把这个理解用在实操上，有三条直接推论：
| 推论 | 理由 | 对应动作 |
|---|---|---|
| 只跑包管理器命令是不够的 | 增强层文件不在包数据库里 | ofed_uninstall.sh 必须单独跑 |
| 跳过脚本会留下旧模块加载配置 | 模块加载顺序与参数由脚本管理的文件决定 | 装完新版可能加载到旧版参数 |
| --force 不是可选项 | 脚本会要求交互确认，自动化流程会卡住 | 脚本化执行必须带 --force |
第三条例外情况在 DKMS 架构下需要特别说明：新架构的模块是在安装时由 DKMS 从源码现场编译的，这意味着卸载后不会有预编译模块残留，但会有 DKMS 的构建记录与本地签名密钥。相关文件路径是 /var/lib/dkms/mok.pub——第十二节与第十三节会回到这条线上。
9.2 课程口径与官方口径的差异
课程讲的是"卸载 MLNX_OFED 或 DOCA-OFED"，官方命令匹配的是 doca 与 flexio 等关键字
这个差异有实际后果，值得点明：官方 DEB 系的匹配表达式是 'doca|flexio|dpa-gdbserver|dpa-stats|dpa-resource-mgmt|dpaeumgmt|dpdk-community'，RPM 系是 grep -i doca。两者的匹配目标都是 DOCA 系包名，而不是 MLNX_OFED 系包名。
结论是：对纯 MLNX_OFED 存量环境，ofed_uninstall.sh --force 才是真正清理 MLNX_OFED 的那一步，前两段包管理器遍历在这种情况下可能匹配不到东西、也不需要匹配。官方把两段写在一起，是因为 DKMS 架构下的目标场景就是"从 DOCA 旧版迁到 DOCA 新版"。
本节关键记忆：2 套命令 + 4 个步骤 + 1 个独立脚本 + 1 处口径差异
- DEB 系 3 步：dpkg --list 遍历 purge → ofed_uninstall.sh --force → apt-get autoremove
- RPM 系 4 步：rpm -qa 遍历 remove → ofed_uninstall.sh --force → yum autoremove → yum makecache（DEB 系没有）
- 1 个独立脚本：/usr/sbin/ofed_uninstall.sh 清理包管理器管不到的厂商增强层文件，--force 用于自动化
- 1 处口径差异：纯 MLNX_OFED 存量环境主要靠 ofed_uninstall.sh 清理，包管理器遍历主要针对 DOCA 系包
十、安装：repo 包、Profile 包与固件更新器
What — 安装阶段要装三样不同的东西
第九节卸载完成后，官方安装流程的正式步骤可以归纳为三样东西 + 两个前置条件。课程把这一节讲得比较简略（“解压 repo 包、跑 apt update、装 DOCA-OFED”），但官方文档给出的是更完整的清单，其中两样漏掉会导致后续问题。
10.1 两个硬性前置条件
官方把这两条写在安装要求里，且措辞是"必须"级别的。它们与 Profile 选型无关，任何 Profile 都适用。
- 前置条件一：已安装与当前运行内核版本匹配的内核头文件
官方给了一个非常实用的自查方法：检查 /lib/modules/$(uname -r)/build 目录是否存在——存在就说明内核头文件已装。命令可以直接写成 test -d /lib/modules/$(uname -r)/build && echo ok。这条检查之所以必要，根源在 DKMS：模块是现场编译的，没有头文件就没有输入。
- 前置条件二：与当前运行内核构建时相同的 gcc 版本
官方明确要求"安装与当前运行内核构建时所用版本相同的 gcc"。这条约束来自 Linux 内核模块的 ABI 约束——模块编译时使用的编译器版本与配置必须与目标内核匹配，否则模块可能编译通过但加载失败。DKMS 管理指南给出的安装包列表里，gcc 是与 dkms 并列的必备项。
10.2 三样东西
以 DEB 系为例，官方安装流程的完整命令序列是五步，课程只讲了其中的两步：
# ===== DEB 系完整安装序列（官方安装与升级页）=====
# 第 1 步：装 DOCA 的本地 repo 包（注意是 repo 包，不是 Profile 包）
host# sudo dpkg -i <repo_file>.deb
# 第 2 步：刷新 apt 索引
host# apt-get update
# 第 3 步：安装目标 Profile（课程讲到的就是这一步）
host# sudo apt install -y doca-all
# 第 4 步：安装固件更新器（课程未提到，但官方流程包含）
host# sudo apt install -y mlnx-fw-updater
# 第 5 步：加载驱动
host# sudo /etc/init.d/openibd restart课程讲到的是第 1、2、3 步的组合，第 4 步（固件更新器）与第 5 步（加载驱动）是官方流程里的独立步骤。把五步对照如下：
| 步骤 | 命令 | 作用 | 课程是否讲到 |
|---|---|---|---|
| 1 | dpkg -i <repo_file>.deb | 把 DOCA 仓库配置装进本机 | 提到（“解压 repo 包”） |
| 2 | apt-get update | 刷新索引，让新仓库可见 | 提到 |
| 3 | apt install -y doca-ofed | 装 Profile，即真正的驱动与库 | 提到 |
| 4 | apt install -y mlnx-fw-updater | 装固件更新器 | 未提到 |
| 5 | /etc/init.d/openibd restart | 加载驱动 | 提到（“重启驱动”） |
官方把 mlnx-fw-updater 放在独立的第 4 步，而不是并入 Profile 安装，这个安排本身携带信息。它意味着固件在架构上被视作一个与内核模块生命周期不同步的独立对象。
这一点可以从三处官方表述交叉印证：
- 安装流程里它是单独一条，不是 Profile 的隐含部分
- 升级流程里它有自己的前置步骤——官方明确要求"升级 mlnx-fw-updater 之前必须先 mst restart"，这说明它有自己的运行时依赖
- 它与 doca-roce / doca-host-basic 的关系被单独点出——官方描述 doca-host-basic 时特意说它"类似 doca-roce 但不含 MFT 与 FW-Updater"，等于从反面确认了 FW-Updater 是一个独立可选件
对 IB 部署的实操含义有两条：其一，固件版本与驱动版本是两个独立的验证对象——驱动装对了但固件是旧的，链路能力可能仍受限；其二，ibstat 输出里的 Firmware version 字段应当作为一条独立的验证项，不能因为端口已经 Active 就认为固件没问题。第九节的升级前置条件（先 mst restart）也印证了这两者是分开管理的。
补充一个与之配套的事实：官方列出的专有（闭源）包默认不安装，需要时单独装。这些包是 clusterkit、dpcp、hcoll、sharp、ibutils2、opensm。注意 opensm 就在这个列表里——对本系列读者这是关键信息，第十三节专门讨论。
10.3 SLES 的两处特例
官方流程对 SLES 单独给了两条规则，选型到 SLES 时需要留意：
- 验证包签名：zypper --gpg-auto-import-keys refresh
- 后续命令全部把 yum 换成 zypper：zypper install -y <profile> / zypper update <profile>
本节关键记忆：2 个前置 + 3 样东西 + 5 步命令 + 6 个专有包
- 2 个前置：匹配运行内核的内核头文件（查 /lib/modules/$(uname -r)/build 是否存在）+ 与运行内核相同的 gcc 版本
- 3 样东西：repo 包（dpkg -i / rpm -Uvh）+ Profile 包（apt install -y doca-ofed）+ 固件更新器（mlnx-fw-updater）
- 5 步：dpkg -i → apt-get update → apt install -y <Profile> → apt install -y mlnx-fw-updater → /etc/init.d/openibd restart
- 6 个专有包默认不装：clusterkit / dpcp / hcoll / sharp / ibutils2 / opensm
- SLES 特例：zypper --gpg-auto-import-keys refresh，其余 yum 全换 zypper
十一、驱动加载：openibd restart 还是 reboot
What — 两种加载方式的官方出处
第十节已经出现过两条并存的官方表述，这一节把它们摊开讲清楚，因为选哪一条会影响变更窗口的长度。
| 表述 | 出处 | 原文 |
|---|---|---|
| 加载驱动 | 《DOCA-Host Installation and Upgrade》 | host# sudo /etc/init.d/openibd restart |
| 重启系统 | 《MLNX_OFED to DOCA-OFED Transition Guide》第 4 步 | Reboot your system and verify that the DOCA-OFED components are working properly |
| 初始化 MST | 《DOCA-Host Installation and Upgrade》加载驱动之后 | host# sudo mst restart |
课程讲的是第一种（“必须重启 DOCA-OFED 驱动”）。三种动作解决的是三个不同层次的问题，把它们分开是理解本节的关键。
11.1 三层含义
下面按"解决什么问题"来区分三条命令。三者的必要性来自 DKMS 架构——模块是现场编译的，编译产物需要在运行时装载；固件管理工具需要自己的初始化；系统级变更则需要完整的重启。
- /etc/init.d/openibd restart — 解决"新模块还没进入内核"
DKMS 在安装过程中编译出模块文件，但编译完成不等于已经加载。这条命令的作用是把 InfiniBand 相关模块装入正在运行的内核。它不重启操作系统，因此变更窗口短。适用场景：驱动刚装完需要立即生效、或日常重载驱动。官方也在 DKMS 指南里用它来处理一个具体问题——BlueField 的 BF-Bundle 版本不低于 2.7.0 但 UEFI/ATF 版本仍显示 N/A 时，执行这条命令。
- mst restart — 解决"固件管理工具的运行时状态是旧的"
这是官方把它单列为一步的原因：固件更新器有独立的运行时依赖。官方在升级流程里特别强调"升级 mlnx-fw-updater 之前必须先执行 mst restart"——这个顺序约束本身就证明了它是一个需要单独初始化的组件，与内核模块的加载是两件事。
- reboot — 解决"系统整体仍处于旧状态"
这一层最彻底，也最慢。官方迁移指南把 reboot 放在第 4 步，说明官方在"从 MLNX_OFED 切到 DOCA-OFED"这个场景下，默认推荐的动作是重启系统。它的必要性来自一点：这次迁移换掉的是整个软件栈，不是单个模块，系统里可能还有依赖旧栈库路径的其他组件，只有完整重启才能确保全部切干净。
给变更窗口的选型建议
把上面三层含义按变更成本排序，可以得到一条实用规则：能用 openibd restart 解决的就不要 reboot，但"迁移"这个动作本身就是全栈替换，不属于可以用短窗口处理的范围。
具体到本篇场景的建议是：首次从 MLNX_OFED 迁移到 DOCA-OFED，按迁移指南走 reboot；之后日常只重载驱动用 /etc/init.d/openibd restart；涉及固件更新器时，先 mst restart 再动它。这个顺序不是推测——它就是官方文档里三条命令各自出现的位置。
11.2 DKMS 架构带来的一个新问题：Secure Boot
这是 DKMS 架构最需要提前规划的一点，课程完全没有涉及
官方明确说明：随着 DKMS 集成，DOCA-Host 不再包含预构建的 NVIDIA 签名内核驱动，模块由 DKMS 在主机上从源码构建并用本地生成的密钥对签名。这句话有一个直接后果：模块签名不再是 NVIDIA 的信任链，而是本机的信任链。
在启用 Secure Boot 的系统上，这意味着 DKMS 生成的公钥必须先注册进系统的密钥数据库。官方给出的流程是：
# 把 DKMS 生成的公钥导入 MOK 列表
# mokutil --import /var/lib/dkms/mok.pub
# 随后重启，按屏幕提示设置一次性注册请求的密码
# 启动过程中 MOK 管理器会提示确认 enrolled 此次请求这四步必须在安装完成之后、重启之前做完，否则模块会因为签名不被信任而无法加载。症状是"驱动装完了但模块加载不了"，而且报错信息指向签名问题而不是安装问题——排查方向容易走偏。这是规划变更窗口时必须留出时间的环节。
两个 DKMS 相关的补充事实
其一，DKMS 的价值在于内核升级时自动重建——官方说明它会在内核头文件更新安装时立即触发针对新内核头编译驱动，从而免除"为每个次要内核版本准备特定二进制"以及"系统更新后手动重编源码"这两项工作。这解释了为什么官方不再为次要 OS 版本发布仓库：DKMS 承担了这个差异。
其二，如果运行的内核版本不受支持，官方给出两条出路：切换到受支持的内核，或者安装 doca-extra 后运行 /opt/mellanox/doca/tools/doca-kernel-support 重建模块。但官方同时明确 doca-kernel-support 不支持定制或非官方内核。如果这台主机跑的是定制内核（常见的 HPC 场景），这条路是走不通的——只能改内核。
本节关键记忆：3 条命令 + 3 层含义 + 1 个 Secure Boot 前置
- /etc/init.d/openibd restart → 模块未进入内核，窗口短
- mst restart → 固件管理工具运行时状态，官方要求升级 fw-updater 前必做
- reboot → 系统整体仍处于旧状态，迁移场景官方默认推荐
- 选型结论：首次迁移走 reboot，日常重载用 openibd restart，动固件前先 mst restart
- Secure Boot 必做：mokutil --import /var/lib/dkms/mok.pub → 重启 → 确认 enrolled，须在安装后重启前完成
- 定制内核无解：doca-kernel-support 明确不支持定制或非官方内核
十二、验证：ofed_info -s 与 ibstat 的判读
What — 验证要回答两个不同的问题
课程在最后安排了两个动作，它们回答的是两个不同的问题，这一点在课程里没有点破，但决定了验证是否完整：
- ofed_info → "装的是哪个版本？"这是软件栈层的问题
- ibstat → "端口现在什么状态？"这是设备层的问题
课程还给出了一条重要的排障提示：如果端口没有回到物理 up 状态，说明驱动重启可能还没完成，等一会儿再试。这条提示对应的是本系列第八篇讲过的状态机——端口需要时间从 Polling / Training 推进到 LinkUp。
12.1 第一步：确认版本已切换
用 ofed_info 确认当前版本，这是迁移前 ofed_info -s 采集的那个值的对照项。官方给出的 doca-info 工具输出形态可以参考，它把版本分成了几个独立的小节：
# 官方给出的 doca-info 输出结构（形态示例，非本机实测）
Versions:
- DOCA Base MLNX_OFED_LINUX-24.07-0.5.5.0
- MFT 4.29.0-127
...
DOCA:
- doca-all 2.8.0-0.0.4
- doca-apsh-config 2.8.0079-1
...
OFED:
- rdma-core 2407mlnx52-1.2407055
- ucx 1.15.0-1.2407055
...这个输出结构里有两个对 IB 部署直接有用的信息：其一，Versions 小节里同时出现 DOCA Base 与 MFT 两个版本号——说明官方把 OFED 基线与 MFT（管理固件工具）当作两个独立对象管理，与第十节的结论一致；其二，OFED 小节里 rdma-core 带着 mlnx 版本后缀（形如 2407mlnx52），这正是第一节所说的"厂商在 rdma-core 共同上游线上做增强"的具体形态。
12.2 第二步：读 ibstat 判端口状态
本系列第八篇已经完整讲过 ibstat 各字段的判读，本篇不重复，只把与迁移验证直接相关的判据挑出来。参考 ArchWiki 收录的 ibstat 正常输出形态：
# ibstat 正常输出形态（ArchWiki 收录的 mlx4_0 双口示例）
CA 'mlx4_0'
CA type: MT25418
Number of ports: 2
Firmware version: 2.9.1000
Hardware version: a0
Node GUID: 0x0002c90300002f78
System image GUID: 0x0002c90300002f7b
Port 1:
State: Active
Physical state: LinkUp
Rate: 20
Base lid: 3
LMC: 0
SM lid: 3
Capability mask: 0x0251086a
Port GUID: 0x0002c90300002f79
Link layer: InfiniBand
Port 2:
State: Down
Physical state: Polling
Rate: 10
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x02510868
Port GUID: 0x0002c90300002f7a
Link layer: InfiniBand这份输出里有一个非常适合做迁移验证的对照结构
Port 1 与 Port 2 的差异恰好覆盖了 IB 部署的三层状态判定——这个示例里两个端口处于三种不同层次的状态，可以当作判读模板背下来：
- Port 1：全通。State: Active（逻辑状态最高档）+ Physical state: LinkUp（物理状态最高档）+ Base lid: 3（已被 SM 分配了 LID）+ SM lid: 3（该子网的 SM 所在 LID 也是 3，说明这个端口自己就是 SM）+ Link layer: InfiniBand
- Port 2：物理层未建立。Physical state: Polling 且 State: Down。按第八节的状态机，物理状态为 Polling 时逻辑状态必然是 Down，这是一个自洽的组合——对应故障方向是线缆或对端，不是软件栈
- Rate 的对照价值：Port 1: Rate: 20 与 Port 2: Rate: 10 不同。速率是协商结果，取链路上最慢设备的值——所以同一个 CA 上两个端口速率不同是正常的，不是故障
对迁移验证而言，判据是三条：① 端口数量与迁移前 lspci 的条数一致；② Link layer 为 InfiniBand 而非 Ethernet；③ Firmware version 非空且符合预期。三条都满足，说明驱动层已经就位。
12.3 驱动层就位，不等于 IB 可用
本系列第八、九、十一三篇反复强调过一个结构性事实：IB 网络的管理是分层委托的。把 ibstat 的字段按"谁负责让它变成这个值"分组，会得到一张非常实用的排障表：
| 字段 | 由谁决定 | 不对时该找谁 |
|---|---|---|
| Firmware version | 网卡固件 / mlnx-fw-updater | 第十节的固件更新流程 |
| Physical state | 链路两端自主训练，与主机软件无关 | 线缆、光模块、对端交换机端口 |
| Base lid / LMC | 子网管理器（SM） | SM 是否运行、是否发现到本节点 |
| SM lid | 子网管理器（SM） | 该子网有无 SM 在运行 |
| State | SM 下发的逻辑状态（Active 是最高档） | 回到上面两行 |
| Link layer | 卡的实际配置（VPI 卡可切 IB 或以太网） | 卡的配置 / 驱动 |
这张表最有价值的一行是 Physical state：它是唯一一个"完全不由主机软件栈决定"的字段。这一事实直接给出一条排障分界线——
- Physical state 停在 Polling / Training → 问题在物理层或对端，升级软件栈不会有帮助
- Physical state 是 LinkUp 但 State 不是 Active → 问题在管理面，此时才轮到查驱动、SMA 与 SM
把这条分界线用在本篇的迁移场景里，含义很直接：如果 ofed_info -s 显示新版本已装、端口也全部 LinkUp，但 State 停在 Down 且 SM lid 为 0，那么问题不在迁移上——驱动已经工作正常，缺的是子网管理器。而 opensm 恰好是第十节提到的默认不安装的专有包之一，这一条线索在下一节展开。
本节关键记忆：2 条命令 + 2 组问题 + 3 条验证判据 + 1 条排障分界线
- 2 条命令各答一问：ofed_info -s 答"哪个版本"，ibstat 答"端口什么状态"
- 3 条验证判据：端口数 = 迁移前 lspci 条数 / Link layer 为 InfiniBand / Firmware version 符合预期
- 两个版本号：Versions 里 DOCA Base 与 MFT 是两个独立管理对象
- 1 条排障分界线：Physical state 是唯一不由主机软件栈决定的字段——不是 LinkUp 就查物理层，LinkUp 但不 Active 就查管理面
- 速率不匹配是正常的：取链路上最慢设备值，同卡多口速率不同不代表故障
十三、InfiniBand 视角的三个特有风险点
Why — 为什么前面十二节还需要这一节
前十二节讲的是通用流程，适用于 RoCE 与 InfiniBand 两种场景。但 DOCA-Host 的 Profile 体系是以以太网与 RoCE 设备为主要出发点设计的，其中有几处差异会直接影响 IB 部署。下面三条按风险程度排序，每一条都能在前面的官方表述中找到依据，不含推测。
13.1 风险一：装错 Profile 导致 InfiniBand 完全不可用
这是三条里后果最严重的一条，因为它的表现具有欺骗性
官方对 doca-roce 的定义包含一句关键限定：它只包含以太网与 RoCE 驱动，不含 IB 专用组件。而 doca-roce 与 doca-host-basic 恰好是安装包最小的两个 Profile，名称看上去又是"更现代的 DOCA 风格"，误选概率不低。
后果的欺骗性在于：驱动装完了、网卡被识别了、甚至 ibstat 也能输出 Ethernet 侧的字段——但这台机器建不了 InfiniBand 子网。按第十二节的排障分界线，这种情形会落在"管理面"一侧，很容易被误判成 SM 问题，实际却是 Profile 选型问题。
防御动作：装之前用第四节那张 Includes 对照表逐档核对，确认目标 Profile 的 Includes 一栏里有 MLNX_OFED 条目。doca-ofed / doca-networking / doca-all 三者都含，doca-roce / doca-host-basic 都不含。
13.2 风险二：opensm 默认不装
这一条对本系列读者最直接
官方《DOCA-Host Installation and Upgrade》有一节专门列出安装流程不会安装的专有（闭源）包，需要时单独安装。完整清单是六个：
DOCA 安装流程默认不装的 6 个专有包
clusterkit 集群管理
dpcp 数据中心路径计算
hcoll 高性能集合通信库
sharp SHARP 聚合 RDMA
ibutils2 InfiniBand 工具集扩展
opensm ★ 子网管理器守护进程
注意 opensm 的官方安装方式：
"Currently, the only way to install these packages is by using
an already-built RPM or DEB file from a similar primary OS."
→ 目前只能从相似主版本 OS 的已构建 RPM/DEB 文件安装
→ 官方给了一张"社区 OS 对应到最相似主版本 OS"的映射表
对本系列读者的含义：
第八篇 子网初始化由 SM 主导 → 没有 SM，LID 不会被分配
第九篇 SM 选举与故障切换 → 没有 SM，压根没有选举
第十一篇 路由引擎与 opensm.conf → 没有 opensm，配置文件无处谈起
即：装了 DOCA-OFED 之后，端口的驱动侧完全正常，
但子网不会自行建立，因为没有任何组件在扮演 SM。结论很直接：doca-ofed 给的是"主机能看见网卡并使用 RDMA"的能力，不包含"子网由谁来管"。前者是驱动与库的事，后者需要 opensm 或交换机自带的 SM。对于托管型交换机（带板载 SM 的型号），SM 由交换机承担，主机不需要装 opensm；对于纯软件 SM 方案，就必须单独装它。
13.3 风险三：Secure Boot 下 DKMS 模块的信任链
这一条在课程里完全没有出现，但它是迁移到新 DKMS 架构后最可能踩到的坑
第十一节已经展开过机制，这里只强调它对 IB 部署的具体影响。官方表述：DKMS 集成后 DOCA-Host 不再提供预构建的 NVIDIA 签名内核驱动，模块由 DKMS 从源码构建并用本地生成的密钥对签名。推论有两条：
- 在启用 Secure Boot 的 IB 计算节点上，模块可能因为签名不被信任而无法加载，此时端口根本不会出现在 ibstat 输出里——连"驱动层就位"都算不上
- 必须在安装完成之后、重启之前完成 mokutil --import /var/lib/dkms/mok.pub 并在启动时确认 enrolled。跳过这一步直接重启，是流程上的一个硬伤
顺带说明另一条与 IB 相关的架构变化：官方已不再为次要 OS 版本发布仓库，统一按主版本发布，由 DKMS 处理内核差异。实际含义是不要去寻找 RHEL 9.4 或 Ubuntu 22.04.3 专用的仓库，一律用主版本仓库。这条规则对 IB 与 RoCE 一视同仁，但它是本次迁移后最需要更新的操作习惯。
把三条风险按"出问题的时刻"排序，会看到一条清晰的规律：
| 风险 | 出问题的时刻 | 传统验收能否发现 |
|---|---|---|
| Profile 选错 | 驱动装完之后 | 不能——网卡能识别，Ethernet 侧一切正常 |
| opensm 缺失 | 驱动装完之后 | 不能——端口 LinkUp 但不 Active |
| Secure Boot | 模块加载时 | 能——ibstat 无输出，明显异常 |
结论是：主机侧的验收项必须分成两组。第一组是"驱动层"检查，判据是 ibstat 有输出、Link layer 为 InfiniBand、Firmware version 正常——这三条通过只说明网卡被驱动接管了。第二组是"子网层"检查，判据是 Base lid 被分配、State 达到 Active——这三条通过才说明这台主机在子网里能传数据了。
两条线对应本系列第八篇的完整因果链：驱动让主机看得见网卡，SM 让网卡在子网里可用。软件栈迁移只作用于第一条线，但验收必须覆盖两条，否则就会出现"驱动装完，一切就绪，业务不通"这类问题。
本节关键记忆：3 条风险 + 1 个专有包 + 2 组验收
- 风险一：装 doca-roce 或 doca-host-basic 装不出 IB→ 缺陷在于 Includes 一栏不含 MLNX_OFED
- 风险二：opensm 属默认不装的 6 个专有包之一→ 缺 SM 则端口 LinkUp 但不 Active；官方说明目前只能用相似主版本 OS 的已构建包安装
- 风险三：DKMS 模块无 NVIDIA 签名→ Secure Boot 须先 mokutil --import 再重启确认
- 2 组验收线：驱动层（ibstat 有输出 / Link layer: InfiniBand / Firmware version 正常）与 子网层（Base lid 已分配 / State: Active）
- 1 个共同点：前两条风险都发生在"驱动成功之后"，只验驱动会漏
十四、FAQ 高频问答（20 组）
本节围绕主机软件栈迁移的 20 个高频易错点展开，题目分四类：概念与定位（Q1–Q5）、Profile 选型（Q6–Q10）、迁移操作（Q11–Q15）、验证与 IB 专属问题（Q16–Q20）。答案中的 Profile 定义、命令原文、时间节点、版本字段均引自文末「参考资料」列出的 NVIDIA DOCA 官方文档与 OpenFabrics Alliance 官网。
- Q1. OFED 到底是什么？和 MLNX_OFED 是什么关系？
OFED 是 OpenFabrics Enterprise Distribution，OpenFabrics Alliance 对它的定义是面向 RDMA 与内核旁路应用的开源软件，覆盖 InfiniBand、RoCE 与 iWARP 三种传输。MLNX_OFED 是同一套软件在 Mellanox / NVIDIA 品牌下的商业发行版。两者不是两个软件栈，而是同一软件栈的社区归一化版本与厂商交付版本。
- Q2. DOCA-OFED 是不是功能更强的 MLNX_OFED？
不是，它与 MLNX_OFED 功能等价。官方原文是 DOCA-OFED is an equivalent package of MLNX_OFED, providing the same functionality，并明确包含同样的内核驱动、用户态库与管理工具，支持相同的操作系统与应用程序。唯一的差别是 DOCA-OFED 不包含任何其他 DOCA 组件——想用 DOCA 的库要选 doca-networking 或 doca-all。
- Q3. 为什么 ConnectX 和 BlueField 的软件栈要合并？
因为它们过去分别依赖 MLNX_OFED 框架与 DOCA 框架，同一机房混用两类设备时主机侧要维护两套安装方式与工具链。官方给出的收益表述是灵活性（两类设备共存于同一软件栈）与投资保护（已有 MLNX_OFED 部署可平移）。合并的粒度是接口与工具链，不是抹平设备差异。
- Q4. "1-to-1 替代"这句话在工程上意味着什么？
意味着三件事被消解了：不需要做功能差异对照表（官方文档本身就是对照表）、不需要为新特性回退做风险评估、已有验证可作为迁移后的起点。决策变量因此压缩到只剩一个——LTS 窗口还剩多久。但要注意"一比一"指功能等价，官方流程仍明确要求先卸载旧包，安装过程有实际操作。
- Q5. MLNX_OFED 什么时候停止支持？不迁移会怎样？
三个节点：2024 年 10 月发布最后一个独立版本，此后无新功能；2024 年 10 月至 2027 年 10 月为 LTS 期，仅提供关键缺陷修复与安全更新；2027 年 10 月 EOL，NVIDIA 不再提供任何支持。官方强烈建议在 EOL 前完成切换。不迁移的真实代价不是当下的稳定性风险，而是未来需要新硬件特性时的被动局面——MLNX_OFED 永远不会新增功能。
- Q6. DOCA-Host 现在到底有几个 Profile？
当前官方文档列出五个：doca-all / doca-networking / doca-ofed / doca-roce / doca-host-basic。课程说四个，是因为录制时 doca-host-basic 尚未列入——引用"四个"这个数字时需要说明版本语境。
- Q7. 跑 InfiniBand 的主机该选哪个 Profile？
只能在doca-ofed / doca-networking / doca-all 三个里选。判据只有一条：看官方 Includes 一栏是否含 MLNX_OFED 条目——这三者都含，doca-roce 与 doca-host-basic 都不含。若目标是与现有 MLNX_OFED 部署平移，选 doca-ofed，因为它就是等价替代品。
- Q8. doca-roce 到底能不能跑 InfiniBand？
不能。官方对它的定义明确限定为只包含以太网与 RoCE 驱动，不含 IB 专用组件，且它是 DOCA_OFED 的子集，存在的目的是接替更早的 MLNX_EN 轻量级软件包。doca-host-basic 同理，官方描述为"类似 doca-roce 但不含 MFT 与 FW-Updater 的基础以太网功能"。
- Q9. 三个可用 Profile 之间怎么选？
看是否需要 DOCA 组件：不需要任何额外 DOCA 功能、要与 MLNX_OFED 等价 → doca-ofed；只要网络相关能力、不承担完整 DOCA 库开销 → doca-networking（官方对 ConnectX 与 BlueField 都推荐这一档）；需要完整 DOCA 能力，或预期将来会引入 BlueField → doca-all。官方提醒 doca-all 中某些组件在默认安装后仍可能需要手动安装。
- Q10. 选了 Profile 就一定能用上所有功能吗？
不一定。官方有两处明确限定：其一，DOCA 的功能受具体设备能力限制——ConnectX 设备无法使用 DPA 这类 DOCA 库，即便装了 doca-all；其二，每个 Profile 只在部分操作系统上受支持，且同一发行版不同架构的支持状态可能不同。Profile 决定装什么，设备与 OS 决定能用什么，这是两条独立约束。
- Q11. 迁移的官方四步是什么？顺序能改吗？
四步是：下载 DOCA-Host 包 → 卸载现有 MLNX_OFED → 用标准 Linux 包管理器安装 DOCA-OFED → 重启并验证。顺序不可颠倒——官方在 DKMS 指南里明确要求移除已装的 DOCA-Host / MLNX-OFED 包，理由是防止冲突。
- Q12. 卸载一定要跑 ofed_uninstall.sh 吗？
要，而且必须带 --force。包管理器删的是包数据库里有记录的部分；/usr/sbin/ofed_uninstall.sh 删的是厂商增强层与模块加载配置——这些不属于任何单一发行版的包，只有厂商脚本能清。不跑它会留下旧模块加载配置，装完新版可能仍加载到旧参数；--force 是为了跳过交互确认，脚本化执行不加会卡住。
- Q13. 下载的是 doca-ofed 的 deb 包吗？
不是，这是最容易出错的一点。下载产物是 DOCA-Host 的 repo 包（DEB 系一个 .deb，RPM 系一个 .rpm），里面装的是仓库配置；真正的 doca-ofed Profile 包是装好 repo 后由包管理器从仓库拉取。官方离线示例把两步分得很清楚：先 rpm -i repo 包，再 dnf install -y doca-ofed。
- Q14. 安装前有哪些硬性前置条件？
两条：已安装与当前运行内核版本匹配的内核头文件——自查方法是看 /lib/modules/$(uname -r)/build 是否存在；已安装与当前运行内核构建时相同的 gcc 版本。这两条的根源都在 DKMS——模块是现场编译的，没有头文件与匹配的编译器就没有输入。RPM 系另有硬性要求：DKMS 版本需不低于 3.2。
- Q15. 官方安装流程里哪一步最容易被漏掉？
固件更新器：apt install -y mlnx-fw-updater（DEB 系）或 yum install -y mlnx-fw-updater（RPM 系）。课程只讲了 repo 包、apt update 与 Profile 三步。官方把它单列为一步，且在升级流程中要求升级它之前必须先 mst restart——这说明固件是与内核模块生命周期不同步的独立对象，ibstat 的 Firmware version 应当作为独立验证项。
- Q16. 装完后怎么验证？验证分几步？
分两步，回答两个不同的问题：ofed_info -s 答"装的是哪个版本"（只看首行的版本号，第一段如 23.07 即年月）；ibstat 答"端口现在什么状态"。驱动层的三条判据是：端口数与迁移前 lspci 条数一致、Link layer 为 InfiniBand、Firmware version 符合预期。
- Q17. 第四步到底是重启驱动还是重启系统？
两个说法都出自官方文档，回答的是不同问题。迁移指南的第 4 步是 Reboot your system（重启系统）；安装与升级页给的加载驱动命令是 /etc/init.d/openibd restart。课程讲的是后者。实际选型：首次迁移走 reboot 最稳妥（换掉的是整个软件栈）；日常重载用 openibd restart；动固件前先 mst restart。
- Q18. 端口装完没回到物理 up 状态怎么办？
课程给的提示是：说明驱动重启可能还没完成，等一会儿再试。技术依据是本系列第八篇的状态机——端口需要时间从 Polling / Training 推进到 LinkUp。但要区分性质：若 Physical state 停在 Polling 且长时间不推进，那是物理层问题（线缆、光模块、对端端口），等也没用；若已是 LinkUp 但 State 不是 Active，那是管理面问题。
- Q19. 装了 DOCA-OFED，端口 LinkUp 但 State 不是 Active，怎么查？
先看 SM lid 与 Base lid。按第十二节的字段归属表，Physical state 是唯一不由主机软件栈决定的字段，它已经 LinkUp 说明驱动侧正常。此时 State 不 Active 属管理面问题——查子网里有没有 SM 在运行。关键背景：opensm 属于默认不安装的 6 个专有包之一，官方说明目前只能用相似主版本 OS 的已构建 RPM/DEB 安装。托管型交换机由交换机自带 SM 承担，主机无需装 opensm。
- Q20. 启用 Secure Boot 的主机装完驱动加载不了，怎么处理？
根源是 DKMS 架构：DOCA-Host 不再提供预构建的 NVIDIA 签名内核驱动，模块由 DKMS 从源码构建并用本地生成的密钥对签名，因此模块签名不再是 NVIDIA 的信任链而是本机的信任链。处理流程是在安装完成之后、重启之前执行 mokutil --import /var/lib/dkms/mok.pub，重启后在 MOK 管理器中确认 enrolled 并输入注册时设置的密码。跳过这步的症状是端口根本不出现在 ibstat 输出里。另外若运行的是定制内核，doca-kernel-support 明确不支持，只能改内核。
FAQ 总纲（口诀式速记）
- 3 个名字：OFA（组织，开发/测试/授权/支持/分发）/ OFED（发行版，面向 RDMA 与内核旁路）/ MLNX_OFED（厂商商业版）
- 2 条代码来源：github.com/linux-rdma 与 git.kernel.org，厂商在其上做增强与回合补丁
- 3 种传输：OFED 覆盖 InfiniBand / RoCE / iWARP——这是 Profile 裁剪风险的来源
- 1 条红线：DOCA-OFED 是 MLNX_OFED 的 1-to-1 替代，不含任何其他 DOCA 组件
- 2 类设备统一：ConnectX 与 BlueField 合并到 DOCA 单一框架，DOCA-OFED 并入 DOCA-Host
- 5 个 Profile：doca-all / doca-networking / doca-ofed（可用于 IB）/ doca-roce / doca-host-basic（不含 IB）
- 7 款支持设备：BF-3 / BF-2 / CX-8 / CX-7 / CX-6 DX LX / CX-5 / CX-4 LX
- 3 个时间点：2024-10 最后独立版（无新功能）→ 2024–2027 LTS（仅缺陷修复与安全更新）→ 2027-10 EOL
- 4 步迁移：下载 repo 包 → 卸载 → 装 Profile → 重启验证，顺序不可颠倒
- 2 套卸载：DEB 系 3 步 / RPM 系 4 步，都必跑 ofed_uninstall.sh --force
- 2 个前置：匹配运行内核的内核头文件 + 相同 gcc 版本（RPM 系另需 DKMS ≥ 3.2）
- 3 条加载命令：openibd restart（模块）/ mst restart（固件工具）/ reboot（系统，迁移场景官方默认）
- 2 组验收：驱动层（ibstat 有输出 / Link layer: InfiniBand / Firmware version）与 子网层（Base lid 已分配 / State: Active）
- 1 条排障分界线：Physical state 唯一不由主机软件栈决定——非 LinkUp 查物理层，LinkUp 不 Active 查管理面
- 1 个常被漏的包：opensm 属 6 个默认不装专有包之一，缺 SM 则子网不成立
- 1 条新架构要求：DKMS 模块无 NVIDIA 签名，Secure Boot 须 mokutil --import 后再重启
- 1 条仓库规则：不再为次要 OS 版本出仓库，一律用主版本仓库，内核差异交给 DKMS
十五、Roadmap 后续预告
本篇是 InfiniBand 专题的第十二篇。它的位置需要说清楚：本系列前十一篇讲的是"网络内部发生了什么"——分层与报文（第一篇）、传输层（第二篇）、子网管理（第八篇）、SM 监控（第九篇）、拓扑变化与路由引擎（第十、十一篇）。本篇第一次把视角移到主机侧——讨论让这些机制得以运行的那套软件栈，以及它正在经历的版本换代。这个视角的切换很重要：协议规范不会变，但承载它的软件栈会换代，而换代期正是故障高发期。
接下来的方向，按由"装得上"向"用得对、再向"看得见"深入的顺序包括：
- RDMA 核心组件的分层与加载：本篇讲了 mlnx-ofed-kernel-dkms 这类模块包被装上系统，但没讲 libibverbs / librdmacm / rdma-core 各自负责什么、ibv_devinfo 里的 transport: InfiniBand (0) 是从哪一层读出来的
- 性能基线与 perftest：本篇把固件版本列为独立验证项，但没讲怎么建立带宽与延迟的基线。IB 社区有大量非 RDMA 的裸流量与 RDMA 流量对照测试，是判断"问题出在驱动还是出在应用"的关键手段
- 存储路径：NVMe-oF 与 NFS-oF 的包与验证：官方在《DOCA-Host Installation and Upgrade》里单列了存储安装一节，涉及 mlnx-nvme-dkms / mlnx-nfsrdma / mlnx-nvme-rdma，且提示要先用包管理器搜索确认完整包名。IB 存储网络的实际部署需求很集中，值得单独展开
- SR-IOV 与虚拟化下的驱动栈：本篇全程讨论物理主机。虚拟机场景下 PF / VF 的驱动归属、opensm 该跑在哪一侧、以及 passthrough 与 SR-IOV 两种方式对 IB 性能与拓扑发现的不同影响
- 固件与驱动版本的配套矩阵：本篇指出固件是独立管理对象，但没有整理 ConnectX 各代型号的固件分支与驱动分支对应关系。升级前查清配套关系，是避免"驱动升上去固件跟不上"的必要功课
- 带内管理路径的建立：本系列第八篇讲了 SM 通过 SMP 发现拓扑，但前提是主机上的 HCA 已经能通信。带内管理路径的建立顺序（物理连通 → 驱动加载 → SMA 启动 → SM 发现）是一个值得单独梳理的端到端流程
- 从 inbox 驱动到 DOCA 驱动：官方在迁移指南里专门为"不装 DOCA-Host"的场景写了一节，说明该方案对内核补丁有特定要求，并给出 RHEL 与 DEB 系的 inbox 包清单。什么场景下 inbox 驱动反而更合适，是一个值得讨论的选型问题
如果你在实践中遇到具体问题——例如 ibstat 里 Link layer 显示为 Ethernet 但卡明明是 IB 型号、端口停在 Polling 长时间不动、Base lid 恒为 0、Secure Boot 机器上模块加载报签名错误、或者拿不准该选 doca-ofed 还是 doca-networking——欢迎在评论区留言，我会挑出共性问题单独扩展一篇专题。
浙公网安备 33010602011771号