不能拆开验证。DOCA 环境中的 BFB、DPU 固件、主机驱动和承载网络、加速或编排功能的服务，必须按同一兼容版本组合规划、部署和验收。只升级其中一项，可能出现管理面可登录、设备可枚举、服务进程也已启动，但数据面转发、RDMA、代表端口、卸载路径或业务连通性异常的状态。管理面正常只能说明基础控制通路尚可用，不能替代业务数据面的验收。
先定义升级对象，而不是只定义软件包
一次变更至少应识别四类对象：DPU 上由 BFB 提供的系统镜像与软件栈、DPU 固件、主机侧驱动，以及主机和 DPU 上依赖驱动能力的服务与配置。不同现场还可能包含内核版本、容器运行时、编排组件、交换网络策略和应用依赖。BFB 不是孤立的安装介质；它落地后形成的运行环境需要与固件接口、主机驱动能力及服务配置共同工作。任何一项的版本、安装方式或持久化配置不同，都可能改变实际组合。
以官方发布组合建立准入基线
升级前应从目标 DOCA 版本对应的发行说明、安装说明和兼容性信息中确认支持范围，不能用“版本号接近”代替兼容性判断。NVIDIA DOCA Documentation提供 SDK 文档入口，应据其中与目标版本匹配的内容核对安装流程、组件要求和限制。涉及网卡、DPU、固件或主机驱动时，还应在NVIDIA Networking Documentation中复核相应产品文档、发行说明与现场硬件适用条件。文档页面会随版本演进，实施时必须固定所用版本并保存复核记录。
哪些情况不能只升一项
紧急修复、硬件维护或既有变更窗口有时会提出仅升级固件、仅刷新 BFB，或仅更新主机驱动。这类操作只有在目标版本官方明确支持该跨版本组合，并且现场依赖已核对时才可采用。反例是主机驱动仍能发现设备、管理工具能读取状态，而数据面所需的队列、端口表示、卸载能力或服务接口与另一侧不一致；此时控制命令未必报错，业务流量却可能失败或退化。对于无法取得明确兼容性证据的组合，应把“单项升级”视为不适用，而不是以管理面可用作为放行依据。
按可回退批次执行变更
- 盘点当前 BFB 标识、DPU 固件、主机驱动、内核、DOCA 组件、服务版本及关键配置，并记录设备状态和业务基线。
- 确定一套经官方资料和现场条件复核的目标组合，明确升级顺序、维护窗口、重启影响及依赖服务的启停顺序。
- 在隔离或低风险节点先完成 BFB、固件、主机驱动和服务的组合升级；每一步保留安装日志、版本查询结果和配置差异。
- 完成必要重启后，再逐项恢复服务与策略，避免旧进程、旧模块或缓存配置继续参与验证。
- 试点通过后按批次扩展，批次间保留观察时间；任何异常均停止扩大范围。
验证必须覆盖管理面和真实数据面
验收应分层进行。管理面检查包括设备枚举、固件与驱动版本读取、服务状态、日志中的加载失败或接口协商错误。数据面检查应按现场实际使用能力选择：主机与 DPU 间连通、业务端口收发、策略生效、隧道或转发表、RDMA 或存储路径、容器网络及应用事务。验证流量应经过目标 DPU 和目标服务链路，而非仅验证本机回环或旁路路径。还应观察错误计数、链路状态、服务日志、丢包或重传迹象以及业务侧成功率，并与变更前基线比较。
把“服务启动”与“功能可用”分开判定
服务已启动、接口已创建、管理 API 可响应，均不足以证明卸载或转发实际生效。应在测试中确认流量命中预期路径，并检查配置是否在重启后仍然存在。若现场使用高可用、编排或滚动升级机制，还需验证故障迁移、节点恢复和重新调度后的数据面，因为这些动作可能重新加载驱动、重建端口或下发策略。没有覆盖实际业务路径的测试，不应作为升级完成的证据。
回退要回到经过验证的完整组合
回退方案应在变更前准备好：保留已验证的 BFB 或镜像获取方式、对应固件与主机驱动安装包、服务配置备份、版本清单和恢复顺序。发生数据面异常时，先冻结后续批次并收集版本、日志、计数器和复现流量证据；若不能在窗口内确认根因，应按既定顺序恢复到上一套完整验证组合，再重新执行管理面和数据面验收。不要只回退最可见的一项来追求快速恢复，否则可能留下新的不匹配状态。
WeChat
Profile