3. BlueField 操作系统与软件栈
BlueField DPU 不是一块“插上就能用”的网卡，它内部运行着一套完整的 Arm 计算环境。理解这套环境的软件栈分层，是后续做安全隔离、卸载加速和容器编排的前提。本节从 DPU 内部的启动与运行环境讲起，逐层向上梳理 DOCA 运行时、Arm 根文件系统、容器化工作负载、驱动与内核模块，最后落到主机与 DPU 之间那条关键的软件边界上。
一、DPU 内部是一台独立的 Arm 计算机
BlueField-2/BlueField-3 内部集成多核 Arm Cortex-A72/A78 处理器、DDR 内存、eMMC 或 NVMe 本地存储，以及用于连接主机的 PCIe 通道和用于连接网络的以太网端口。它拥有自己的固件（UEFI/ATF）、引导加载程序和操作系统，因此可以像一台服务器一样独立启动、独立管理。这一点决定了 DPU 上的软件栈与主机软件栈是两套并行的系统，而不是主机系统的一个驱动扩展。
DPU 的启动链路大致为：上电后由板载固件完成初始化，加载 Arm 侧的引导程序，随后从本地存储或通过网络引导加载 Arm 根文件系统，最后启动用户态服务与 DOCA 运行时。主机侧则通过 PCIe 枚举到 BlueField 呈现的多个 PCIe 功能（PF/VF），加载对应的主机驱动。两条链路在物理上共享一块芯片，在软件上却各自独立。
二、Arm 根文件系统：Ubuntu 与 CentOS 的选择
DPU 上运行的操作系统通常以 Arm64 根文件系统的形式提供。NVIDIA 官方为 BlueField 提供基于 Ubuntu 的 DOCA 基础镜像，同时也支持 CentOS/RHEL 系的 Arm64 发行版。选择哪一个，主要取决于团队已有的运维体系：如果主机侧统一使用 Ubuntu，DPU 侧沿用 Ubuntu 可以复用 apt 源、systemd 单元和配置管理工具；如果企业标准是 RHEL 系，则选用 CentOS 或 Rocky 的 Arm64 版本更利于统一补丁与合规流程。
根文件系统一般部署在 DPU 本地 eMMC 或 NVMe 上，也可以配置为从主机通过 PCIe 提供的虚拟块设备引导，或通过网络（PXE/iSCSI）引导。本地存储方案启动快、与主机解耦，适合生产环境；网络引导便于批量部署和镜像统一更新，但依赖网络可用性。无论哪种方式，DPU 的根文件系统都应视为一个需要独立做安全加固、日志采集和版本管理的节点系统。
三、DOCA 运行时：把硬件能力抽象成服务
DOCA 是 BlueField 的软件开发框架，它由 DOCA 运行时（runtime）、驱动、库和一组可编程组件构成。DOCA 运行时的核心作用，是把 DPU 上的硬件加速能力（如加密、正则匹配、压缩、流量整形、时间同步）抽象成用户态可调用的服务，并通过 gRPC 等接口暴露给主机或 DPU 上的应用。
典型的 DOCA 服务包括 DOCA 加密服务、DOCA 正则服务、DOCA 压缩服务、DOCA 流控服务和 DOCA 遥测服务等。这些服务在 DPU 上以守护进程形式运行，主机侧应用通过 DOCA SDK 或直接调用服务接口来使用加速能力，而无需关心底层硬件队列和寄存器细节。DOCA 运行时还负责设备初始化、资源分配和服务生命周期管理，是 DPU 软件栈中承上启下的关键一层。
四、容器化工作负载：DPU 上的 Kubernetes 节点
由于 DPU 运行完整的 Arm64 Linux，它天然可以运行容器。NVIDIA 提供了 DOCA 容器镜像和 Kubernetes 设备插件，使 BlueField 可以作为 Kubernetes 集群中的一个 Arm 节点被纳管。这样，安全策略、网络功能、存储代理等原本跑在主机 CPU 上的工作负载，可以下沉到 DPU 的容器中运行，主机侧只保留业务容器。
在 DPU 上运行容器时需要注意几点：镜像必须是 Arm64 架构；容器需要访问 DPU 的加速设备时，要通过设备插件或直接挂载 /dev 下的相关设备节点；网络命名空间和主机网络的关系需要明确，因为 DPU 同时承担主机流量和自身管理流量的转发。一个常见的做法是把 DPU 上的容器分为“基础设施容器”（如 OVS、防火墙、遥测代理）和“管理容器”（如监控、日志），前者通常使用 host 网络以获得最佳转发性能。
五、驱动与内核模块加载
DPU 软件栈涉及两侧驱动。主机侧需要加载 mlx5_core、mlx5_ib 等 PCIe 驱动，使主机能够识别 BlueField 呈现的网卡、RDMA 和存储功能；DPU 侧则需要加载对应的 Arm 版本驱动以及 DOCA 相关的内核模块。DPU 侧的模块加载通常由 systemd 服务或 modprobe 配置在启动时完成，例如加载用于加密加速、正则加速或流表卸载的模块。
排查驱动问题时，可以在 DPU 上执行 lsmod 查看已加载模块，用 dmesg | grep -i mlx 观察驱动初始化日志，用 lspci 确认 PCIe 设备枚举情况。主机侧则用 lspci -d 15b3: 确认是否识别到 Mellanox/NVIDIA 设备。两侧驱动版本需要与 DOCA 版本匹配，否则可能出现服务启动失败或加速功能不可用。
六、主机与 DPU 的软件边界
主机与 DPU 之间的软件边界，是理解整套架构最关键的一点。物理上，两者通过 PCIe 连接；软件上，它们各自运行独立的操作系统，通过 PCIe 上的虚拟通道、共享内存或网络接口进行通信。主机看到的 BlueField 可能表现为多个 PCIe 功能：一个用于管理的网络接口、一个或多个用于数据平面的 VF、以及可能出现的存储或 RDMA 功能。
边界上的数据流大致是：主机业务流量通过 VF 进入 DPU，DPU 上的转发或加速逻辑处理后，从 DPU 的物理端口发出；反向流量同理。管理流量则通过主机侧的 PF 或独立的带外管理口进入 DPU 的管理系统。安全隔离策略通常就部署在这条边界上——DPU 可以在流量进入主机之前完成过滤、加密、审计，从而实现“主机不可信、DPU 可信”的隔离模型。
七、版本匹配与常见问题
DPU 软件栈最容易出问题的地方是版本不匹配。DOCA 版本、DPU 固件版本、主机 OFED 版本和 Arm 根文件系统版本之间存在兼容矩阵。例如，DOCA 2.x 通常要求 BlueField-2 固件不低于某个版本，主机侧 OFED 也需要对应版本。如果主机驱动过旧，可能出现 VF 无法创建或 RDMA 设备不可见；如果 DPU 侧 DOCA 服务启动失败，则加速功能会静默降级为软件路径，性能明显下降。
建议在部署前先确认三件事：DPU 固件版本（mlxfwmanager 或 flint -d /dev/mst/... q）、DOCA 版本（doca_version 或查看 /opt/mellanox/doca 目录）、主机 OFED 版本（ofed_info -s）。三者对齐后，再启动 DOCA 服务和容器工作负载，可以避免大部分“功能不生效”的问题。
总结来看，BlueField 的软件栈可以理解为“两套系统、一条边界”：主机侧是传统服务器软件栈加 PCIe 驱动，DPU 侧是独立的 Arm Linux 加 DOCA 运行时和容器工作负载，两者通过 PCIe 上的 PF/VF 和虚拟通道交互。掌握根文件系统的部署方式、DOCA 服务的运行机制、容器化工作负载的编排方法，以及驱动与内核模块的加载顺序，才能在实际项目中把安全隔离和基础设施加速真正落地。