DOCA SDK 架构

DOCA 提供了用于网络和数据处理可编程性的库，这些库利用了 NVIDIA® BlueField® 网络平台（DPU 或 SuperNIC）和 NVIDIA® ConnectX® NIC 硬件加速器。

DOCA 软件框架构建于 DOCA Core 之上，DOCA Core 为 DOCA 库提供了一个统一的软件框架，以形成一个或多个 DOCA 库的处理管道或工作流构建。

DOCA SDK 允许应用程序将资源密集型任务（例如，加密和压缩）卸载到硬件。DOCA 还允许应用程序卸载与网络相关的任务（例如，数据包捕获、RDMA 发送）。因此，BlueField 和 ConnectX 提供了专用的硬件处理单元来执行此类任务。

DOCA 设备子系统提供了被称为“设备”的硬件处理单元的抽象。

DOCA 设备子系统提供以下方法：

• 发现由 DPU/SuperNIC/NIC 提供的可用硬件加速单元

• 查询可用硬件加速单元的功能和属性

• 打开设备以使库能够分配和共享硬件加速所需的资源

在给定的系统中，可能存在多个可用设备。应用程序可以根据以下特征拓扑（例如，PCIe 地址）和/或功能（例如，加密支持）选择设备。

DOCA Core 支持两种 DOCA 设备类型

• 本地设备 – 这是本地系统（BlueField 或主机）中暴露的实际设备，可以执行 DOCA 库处理作业。这可以是 PCIe 物理功能 (PF)、虚拟功能 (VF) 或可扩展功能 (SF)

• 代表设备 – 这是本地设备的表示。被代表的本地设备通常在主机上（SF 除外），而代表始终在 BlueField 端（BlueField 上主机侧设备的代理）。

下图提供了主机本地设备在 BlueField 上具有代表的示例

该图显示了连接到主机（左侧）的 BlueField（图的右侧）。主机具有物理功能 PF0 和子虚拟功能 VF0。

BlueField 端每个主机功能都有一个代表设备，比例为 1 对 1（例如，hpf0 是主机 PF0 设备的代表设备，等等），并且每个 SF 功能也有一个代表，这样 SF 及其代表都位于 BlueField 中。

硬件处理任务需要数据缓冲区作为处理操作的输入和/或输出。应用程序负责提供输入数据和/或读取输出数据。为了实现最佳性能，SDK 使用零拷贝技术将数据传递到硬件。为了允许零拷贝，应用程序必须预先注册将保存数据缓冲区的内存。内存管理子系统提供了一种注册内存和管理已注册内存上的数据缓冲区分配的方法。

内存注册

• 定义用于保存数据缓冲区的用户应用程序内存范围

• 允许一个或多个设备访问内存范围

• 定义访问权限（例如，只读）

数据缓冲区分配管理

• 允许分配覆盖已注册内存中子范围的数据缓冲区

• 允许在已注册内存上使用内存池语义

DOCA 内存具有以下主要组件

• doca_buf – 描述数据缓冲区，并用作 DOCA 库中各种硬件处理任务的输入/输出

• doca_mmap – 描述已注册的内存，设备可通过一组权限访问该内存。doca_buf 是 doca_mmap 表示的内存范围中的一个段。

• doca_buf_inventory – 具有相同特征的 doca_buf 池（更多信息请参见“DOCA Core Buffers”和“DOCA Core Inventories”部分）

下图显示了 DOCA 内存子系统中的各种模块

该图显示了一个 doca_buf_inventory，其中包含 2 个 doca_buf。每个 doca_buf 指向内存缓冲区的一部分，该部分是 doca_mmap 的一部分。mmap 填充了一个连续的内存范围，并注册了 2 个 DOCA 设备，dev1 和 dev2。

DOCA SDK 引入了利用硬件处理单元的库。每个库都定义了用于实现特定处理任务（例如，加密）的专用 API。该库抽象了与硬件操作相关的所有底层细节，使应用程序可以专注于重要的事情。这种类型的库称为上下文。由于上下文利用硬件处理单元，因此需要设备才能运行。此设备还确定该上下文可以访问哪些缓冲区。上下文以任务和事件的形式提供硬件处理操作 API。

任务

• 应用程序准备任务参数

• 应用程序提交任务；这会向相关的硬件处理单元发出请求

• 硬件处理完成后，应用程序以回调的形式接收完成

事件

• 应用程序注册事件。这会通知硬件在事件发生时进行报告。

• 每次硬件识别到事件已发生时，应用程序都会以回调的形式接收完成

由于硬件处理本质上是异步的。DOCA 提供了一个对象，允许等待处理操作（任务和事件）。此对象称为 Progress Engine (PE)。PE 允许使用以下方法等待完成：

• 忙等待/轮询模式 – 在这种情况下，应用程序重复调用一种方法来检查是否发生了完成

• 通知驱动模式 – 在这种情况下，应用程序可以使用 OS 原语（例如，linux event fd）在发生某些完成时通知线程

一旦发生完成，无论是任务还是事件引起的，都会作为 PE 方法的一部分调用相关的回调。

单个 PE 实例允许等待来自不同上下文的多个任务/事件。因此，应用程序可以为每个线程使用单个 PE。

下图说明了各种 DOCA 模块的组合如何结合 DOCA 跨库处理运行时。

该图显示了 3 个上下文使用同一设备，每个上下文都有一些应用程序已提交/注册的任务/事件。所有 3 个上下文都连接到同一个 PE，应用程序可以使用同一个 PE 一次等待所有完成。