📚 课程目录第1章 DOCA全景与开发环境搭建

1. DOCA全景与开发环境搭建

DOCA（Data Center Infrastructure on a Chip Architecture）是 NVIDIA 面向 BlueField DPU 与 ConnectX 网卡推出的软件框架，目标是把数据中心里原本由 CPU 承担的虚拟交换、存储、安全、遥测、AI 推理等基础设施任务，卸载到 DPU 上执行。理解 DOCA 的关键，不是把它当成一个库，而是把它看成"一套运行时 + 一组服务 + 一套开发接口"的组合：底层是 DPU 上的 DOCA 运行时与固件，中间是 DOCA 服务（如 DOCA Flow、DOCA App Shield、DOCA Telemetry），上层才是开发者调用的 DOCA 库与 API。

一、DOCA 架构与 BlueField 的角色

BlueField DPU 本质是一块"带网络接口的嵌入式服务器"：它拥有独立的 Arm 多核 CPU、DDR 内存、eMMC 存储，并通过 PCIe 与主机相连，同时对外提供两个或多个高速以太网口。主机侧看到的是一个 PCIe 设备，DPU 侧看到的是一台可以独立运行 Linux 的机器。这种"双系统"结构决定了 DOCA 程序有两种典型部署位置：运行在 DPU 的 Arm 核上（卸载路径），或运行在主机 CPU 上并通过 DOCA 接口操作 DPU（控制路径）。

从数据流角度看，BlueField 内部存在三条关键通路：主机到网络的流量（Host → Network）、DPU 自身到网络的流量（DPU → Network），以及主机与 DPU 之间的 PCIe 通道。DOCA 的价值就在于让开发者能够用统一 API 去编排这三条通路上的转发、过滤、加密与统计逻辑，而不必直接写 Verilog 或操作底层固件寄存器。

二、软件栈组成与版本对应关系

DOCA 软件栈自上而下大致分为四层。最上层是 DOCA 应用与容器，开发者用 C/C++ 或 Python 调用 DOCA 库；第二层是 DOCA 库与 API，包括 DOCA Flow（流表编排）、DOCA RDMA（远程直接内存访问）、DOCA Comch（主机与 DPU 通信通道）、DOCA Telemetry（指标采集）等；第三层是 DOCA 服务，以 systemd 服务或容器形式常驻 DPU；最底层是 BlueField 固件与 BFB 镜像，决定了 DPU 启动后自带哪些能力。

版本匹配是新手最容易踩的坑。DOCA 版本、BlueField 固件版本、主机驱动版本三者必须落在 NVIDIA 官方兼容矩阵内。例如 DOCA 2.6 通常要求 BlueField-2 固件不低于 24.35 系列，主机侧 MLNX_OFED 或 DOCA-Host 驱动需与之对应。若固件过旧，doca_caps 可能报告某些能力不可用，程序在初始化阶段就会返回 DOCA_ERROR_NOT_SUPPORTED。

三、开发工具链安装与验证

安装分主机侧与 DPU 侧两步。主机侧推荐使用 DOCA-Host 安装包，它会同时装入驱动、用户态库与示例程序：

# 主机侧（以 Ubuntu 22.04 为例，示例版本号）
wget https://developer.download.nvidia.com/compute/doca/host/doca-host_2.6.0-ubuntu2204_amd64.deb
sudo dpkg -i doca-host_2.6.0-ubuntu2204_amd64.deb
sudo apt-get update && sudo apt-get install -y doca-host

# 验证主机侧安装
doca_ver
# 预期输出示例：doca-host 2.6.0, mlnx-ofed 24.04, kernel 5.15.0

DPU 侧通常通过 BFB 镜像刷写后，在 DPU 的 Arm 系统内安装 DOCA 运行时。若使用容器化部署，可直接拉取官方镜像：

# 在 DPU 的 Arm 系统内
docker pull nvcr.io/nvidia/doca/doca:2.6.0-devel
docker run --rm -it --privileged nvcr.io/nvidia/doca/doca:2.6.0-devel bash

# 容器内验证
doca_caps
# 预期输出示例：Flow: supported, RDMA: supported, Telemetry: supported

验证环节建议按"驱动 → 库 → 能力 → 示例"四步走。先用 lspci | grep Mellanox 确认主机能识别 BlueField 设备；再用 doca_ver 确认库版本；接着用 doca_caps 查看当前固件与驱动组合下哪些 DOCA 能力可用；最后运行一个官方示例，例如 doca_flow_grpc 或 doca_telemetry 的 demo，观察是否能正常初始化并输出日志。若 doca_caps 中某项显示 unsupported，应优先检查固件版本，而不是反复重装库。

建议在首次搭建环境时记录一份"版本快照"：DOCA 版本、固件版本、主机驱动版本、内核版本、DPU OS 版本。后续遇到兼容性问题时，这份快照能快速定位是环境漂移还是代码问题。

四、一个最小可运行示例的观察点

以 DOCA Flow 为例，一个最小程序通常包含：初始化 DOCA 上下文、创建 Flow 端口、下发一条匹配规则、启动管道、观察计数器。运行后应重点观察三类输出：初始化阶段是否打印 DOCA_ERROR；规则下发后 doca_flow_port_pipes_dump 是否能列出刚创建的 pipe；以及通过 doca_flow_query 读取的包计数是否随流量增长。若计数始终为零，常见原因是规则匹配字段与实际报文不一致，或流量没有经过被绑定的端口。

完成本章环境搭建后，你应当能够在主机上编译 DOCA 程序、在 DPU 上运行 DOCA 服务，并用 doca_caps 与官方示例确认整条链路可用。这是后续所有章节——无论是流表编排、RDMA 加速还是遥测采集——的共同起点。