【论文阅读】使用 OpenMP API 进行 DPU 卸载编程

今天我们来看一篇2023年由西班牙巴塞罗那超级计算中心的研究人员穆罕默德・乌斯曼（Muhammad Usman）、塞尔希奥・伊塞特（Sergio Iserte）、罗杰・费雷尔（Roger Ferrer）和安东尼奥・何塞・佩尼亚（Antonio José Peña）发表的论文《DPU Offloading Programming with the OpenMP API》。

原文链接：https://dl.acm.org/doi/10.1145/3624062.3624165

一段话总结：

这篇文章聚焦于DPU的 OpenMP 卸载编程，首次提出基于 LLVM 和 BlueField DOCA SDK 的 ODOS（OpenMP DOCA Offloading Support）框架，支持 OpenMP 标准卸载语义，相比传统 MPI 编程模型更易使用且提升了编程生产力。

通过在BlueField 2 和 3 DPU 上的性能测试表明，ODOS 在多种HPC基准测试中性能可与 MPI 基线竞争，且 OpenMP 编程范式显著简化了开发流程。该研究为HPC领域DPU卸载编程开辟了新方向，在DPU性能也在大幅提升的趋势下，有望推动 DPU 在更多应用场景的广泛应用。

一、介绍

DPU是一类新型的可编程片上处理器系统（SoC），它集成了软件可编程处理单元（CPU）、高性能网络接口以及其他加速引擎。

目前量产DPU的主要制造商是英伟达（NVIDIA），该公司为其 BlueField DPU 设备提供了专门的软件开发工具包（SDK）——DOCA。

DPU设备最初旨在分担传统 CPU 在数据中心网络相关任务中的负载，通过专用硬件优化提升数据处理效率，尤其适用于需要高吞吐量和低延迟的网络密集型场景，如数据中心内的网络流量管理、存储I/O 操作加速以及数据加密解密等任务，从而释放 CPU 资源用于更复杂的计算工作。

DPU设备商的通用可编程CPU的存在为HPC领域打开了更多机遇之门。到目前为止，这些机遇已被探索用于卸载MPI操作，同时也用于执行通用计算。

然而，下面两种当前可选的编程方式，从编程生产力和可移植性方面来看，都不理想：

（1）方式一：使用低层级的DOCA API；

方式一对HPC领域的开发者而言层级过低，从而会带来一系列影响。

（2）方式二：利用DPU可作为自托管设备运行并作为网络中的常规计算节点暴露的特性。

自托管指的是：DPU可独立承载操作系统、驱动程序及应用程序，无需完全依赖主机CPU 即可自主执行任务。

常规计算节点指的是：DPU 可通过网络接口被集群或分布式系统识别为标准的计算单元）

方式二，从编程生产力和可移植性角度来看也远非理想：应用开发者需要处理在两种差异极大的处理器架构中执行的MPI进程（rank），这会导致性能差异显著，且与MPI编程模型的设计初衷相悖。

MPI编程模型通常假设各计算节点的架构一致性，以确保进程间通信和负载均衡的自然性。

当MPI 进程运行在两种差异极大的处理器架构（如 CPU 与 DPU）上时，会出现以下问题：

性能不一致性：不同架构的计算能力、内存带宽、通信延迟等特性差异显著，导致同一MPI 任务在不同节点上的执行效率失衡。

开发复杂度陡增：开发者需要额外处理架构差异带来的性能优化问题（如数据分片、通信同步），这违背了MPI “抽象底层架构” 的设计初衷，使编程过程变得 “不自然”。

在HPC领域，OpenMP是应用最广泛的编程模型之一，OpenMP能利用多核处理器架构的数据并行性。

从4.0版本开始，OpenMP标准纳入了将并行计算卸载到设备的功能。

这种支持主要在GPU计算中得以实现，并被广泛采用。

在这篇文章的相关工作中，作者们在LLVM中实现了对OpenMP卸载至NVIDIA BlueField DPU的支持。这一方案被命名为ODOS（OpenMP DOCA Offloading Support）。

ODOS支持标准的OpenMP卸载语法和语义。与传统OpenMP GPU卸载支持的唯一区别在于：由于ODOS的目标是多核处理器而非大规模并行架构，因此期望用户利用传统的并行化语义（如parallel for），而非GPU等典型并行设备特有的语义（如teams distribute）。

这篇文章将在描述ODOS方法后，讨论现有MPI方法与ODOS支持的OpenMP卸载针对DPU设备的可编程性。

这篇文章的结论是：OpenMP卸载对应用开发人员而言是一种更为自然和简便的方法。

这篇文章也会通过一系列基准测试对解决方案进行评估，测试证明通过原生BlueField SDK（DOCA）使用OpenMP进行DPU卸载的性能，可与基于MPI的基线相媲美。

NVIDIA BlueField 3 DPU比BlueField 2强大得多，3系列支持带宽高达400 Gb/s的PCIe 5.0、16核ARM A78处理器和32GB DDR5内存，因此它的应用范围会比BlueField 2设备更广泛。

已发布的NVIDIA BlueField 4，预计将具备更高的带宽和计算能力。

ODOS软件结合BlueField 3设备的新功能，有可能在HPC领域引发关于DPU协处理器使用的更广泛研究。

而OpenMP的使用将大大降低对这些设备进行编程的工作量。

二、背景

下文简要介绍ODOS针对的硬件，以及硬件供应商提供的本地通用编程可能性。

1.BlueFiled DPU

BlueField DPU是NVIDIA开发的DPU，它将数据处理能力与集成网络功能相结合，在单一芯片上集成了ARM CPU核心、网络接口和特定领域加速器。

这种集成使得在数据中心环境中能够采用高效且流线型的数据处理方式。

通过结合网络和处理能力，BlueField DPU可以卸载传统上由独立组件执行的任务，有望提升性能、降低延迟并提高整体系统效率。

BlueField DPU的网络功能包括高速InfiniBand接口和对各种网络协议的支持。这使其能够进行高效的数据包处理、网络虚拟化和增强的安全功能。

集成的ARM CPU核心提供了可运行操作系统和应用程序的通用处理能力。

相对普及的BlueField 2 DPU具有PCIe 4 、8个ARM A72核心和32GB板载DDR4 DRAM，而较新的BlueField 3版本支持PCIe 5，并配备16个ARM A78处理器和64GB DDR5 DRAM。

2.对BlueField DPU 进行编程

(1)DOCA

DOCA使开发人员能够利用NVIDIA BlueField DPU的功能，并为网络、安全、存储、HPC或AI应用提供行业标准的开放API和框架。

这些框架通过集成的NVIDIA加速包简化了应用程序的卸载过程。

DOCA 包含丰富的 API 集和抽象概念，可简化网络与安全应用程序的开发。

借助DOCA，开发人员能够利用 BlueField DPU 的可编程性和加速能力，实现虚拟交换、虚拟路由、负载均衡和防火墙等高级网络功能。

它提供了高性能数据路径和灵活的可编程管道，支持自定义数据包处理。

(2)MPI

由于DPU设备可运行操作系统并作为独立计算节点暴露于网络，当前可在这些设备上部署MPI进程以执行通用代码。因此，这些设备具有独立的进程编号（rank），如图1所示。

图片

应用程序可通过MPI的connect/accept语义部署互通信道，或通常借助通用MPI启动器的“:”语法执行MPI MPMD（多程序多数据）会话。

不论如何，CPU和DPU执行独立的MPI进程编号，这给应用开发者带来了负担——他们必须处理在不同架构中执行的不同MPI进程，而这些架构会产生差异极大的性能表现。

三、相关工作

和本文相关的聚焦于HPC解决方案的相关工作均于2020年后发表，这表明本研究领域尚处于新兴阶段，且科学界对其兴趣日益浓厚。

下文将自下而上呈现相关工作内容：从编译器到运行时，再到用户应用程序。

1.LLVM/OpenMP编译器基础设施中已公开提供远程OpenMP卸载的低开销实现方案。

该研究包含对微基准测试的详细分析，以及两个HPC代理应用的扩展性结果。

核心思想是在主机端的目标无关库与远程系统的目标相关库之间建立透明通信通道，此外，该方案还利用了远程过程调用（RPC）机制。

在分布式异构系统中，与消息传递接口（MPI）方案不同，远程OpenMP卸载无需修改源代码、编译器或编程语言。不过，该研究中提出的版本目前仅适用于远程CPU和GPU，尽管其可能被扩展至其他设备类型。

2.Three-Chains框架利用了远程二进制代码注入的思想。

该框架可同时卸载计算任务与通信任务，能将代码传输至任意网络设备并在接收端运行。

它借助LLVM编译器的BitCODE表示形式，在执行端完成编译过程。

Three-Chains框架在编译期间提供函数缓存机制，这可转化为在通用硬件上的更快执行。类似地，Floem项目为卸载任务提供了语言、编译器和运行时支持，但专门针对智能网卡（SmartNICs）。

3.BluesMPI 是一项可确保MPI全对全（alltoall）集合操作的通信与计算完全重叠的技术，同时其纯通信延迟与基于CPU加载的设计相当。

该技术旨在实现将MPI_Ialltoall从主机CPU卸载到智能网卡（Smart NIC）或DPU时的最佳纯通信延迟。

通过OSU微基准测试对BluesMPI进行评估的结果显示，其将MPI_Ialltoall操作的执行时间最多缩短了44%，在P3DFFT应用中最多缩短了33%。

对于复杂的通信模式，利用现有标准无法实现将MPI通信无缝卸载至BlueField的需求，因此研究中还提出了新的MPI API来描述此类模式并将其卸载至DPU，以实现通信卸载。

4.能够利用DPU来卸载某些计算阶段的MiniMD分子动力学迷你应用版本。

具体而言，其作者创建了一个MiniMD变体，其中DPU用于在邻居构建迭代过程中执行粒子间的力计算，而主机则负责重建邻居列表。与原始代码相比，这个新的MiniMD版本实现了高达20%的加速比。

5.研究人员还提出并评估了多种将深度学习（DL）训练阶段高效卸载至DPU的新型设计。

深度学习训练过程可能包含多个阶段：数据增强、模型训练或训练模型的验证。

传统上，由于缺乏额外计算资源来卸载深度学习训练的独立阶段，这些阶段大多在CPU或GPU上按顺序执行。

在该研究中，作者将数据增强和验证阶段与训练阶段解耦，以便将其卸载至DPU，声称整体训练时间最多可提升17.5%。

与上述文献中披露的相关工作不同，这篇文章的工作首次将DPU网络协处理器作为通用计算的本地加速器，以减轻应用开发人员的工作负担。此外，此前没有研究利用BlueField设备的原始SDK DOCA（而基于NVIDIA GPU的类似CUDA的研究则很常见）；相反，以往的工作采用的替代方案会增加开销（如网络开销）和/或进行特定的代码重构。

四、这篇论文的解决方案介绍

本节详细介绍了将BlueField DPU的卸载功能集成到LLVM/OpenMP目标卸载架构中的过程。

与其他方法不同，该解决方案完全基于BlueField SDK（即DOCA）提供的原生通信机制，避免了其他上层通信层带来的不必要开销。

这种基于DOCA 的解决方案由三个主要模块组成，后续将详细介绍这三个模块：

- 交叉编译：LLVM 的一项功能，用于生成可在 DPU 中运行的二进制文件。

- OpenMP BlueField 插件：用于与BlueField DPU 交互的运行时。

- OpenMP DOCA 服务：在BlueField DPU 上运行，通过 OpenMP 插件接收并完成从主机发来的请求。

1.交叉编译

当目标架构与主机架构不同时，需要进行交叉编译。

BlueField设备配备了64位ARM处理器，这不一定与主机处理器相同。

例如，假设主机为x86 Intel架构，则需要对卸载的代码进行交叉编译，以使其能够在BlueField设备上正确执行。

交叉编译是LLVM的内置功能，它支持多种架构，包括x86-64、aarch64和riscv64。

LLVM项目遵循一个全局假设，即系统中仅存在一个sysroot（系统根目录），换句话说，只有一个根目录用于定位头文件和库文件。

BlueField设备运行其自身的操作系统及相应的文件系统，因此拥有独立的sysroot。

本解决方案对LLVM/Clang进行了平台特定的修改，以支持针对BlueField DPU的交叉编译。

修改后的编译器会生成“胖” 主机二进制文件，该文件内部包含交叉编译后的目标二进制代码。

这种机制是LLVM 原生支持 GPU 卸载的延伸 —— 通过将目标代码嵌入主机二进制，实现跨架构的无缝部署。

最终生成的插件二进制镜像专为BlueField DPU 编译，可通过 DOCA 框架传输至目标设备（DPU），作为独立的Linux 主机环境运行。

OpenMP BlueField 插件则负责调用该交叉编译的目标镜像，在 BlueField DPU 上执行卸载的代码任务。

源代码会被Clang编译两次以生成中间表示（IR）：一次为宿主系统生成IR，另一次单独为目标设备生成IR。

随后，Clang Offload Packager工具会将这些IR合并并生成最终的IR，之后对其进行编译和链接。

与基于host链接器的传统链接方式不同，在链接胖二进制文件时，依赖Clang Linker Wrapper。Clang Linker Wrapper可针对具有不同sysroot的架构进行编译（默认情况下，Clang仅假定存在一个sysroot）。

通过这种新方法，能够生成包含待卸载的交叉编译目标区域的合适胖二进制文件。

2.OpenMP BlueField 插件

OpenMP BlueField 插件通过定义标准化接口，实现 OpenMP 运行时对 DPU 设备的管理与控制。

在LLVM 14.06 版本中，该插件需实现以下核心方法，以支撑设备交互的全流程操作：info, loading binary, data transfer, 和running target blocks.

ODOS实现的BlueField插件与OpenMP DOCA服务通过DOCA通信通道（CC）模块进行交互。

CC模块由厂商提供，用于在主机与DPU之间实现数据交换。CC提供了基于PCIe的安全高效通信抽象层，并且通过在进程间使用信号量和锁定资源，能够支持多应用并发运行。

需实现的核心方法描述如下：

(1)信息查询（Info）：

从DOCA核心模块及后续相关模块收集基础信息。这些信息有助于识别设备并将其与对应的设备编号关联.

此外还能通过DOCA核心模块提供设备功能的进一步信息，例如接口名称、InfiniBand（IB）设备名称、PCIe地址等。 

(2)二进制加载（Load Binary）：

OpenMP运行时会为单个共享对象中的所有目标区域加载二进制文件。

运行时提供所有所需symbols 的名称，并期望返回每个symbol的地址。

镜像通过DOCA通信通道（CC）发送至BlueField DPU。

DOCA OpenMP服务使用`dlopen`加载镜像，并通过每次`dlsym`调用返回每个请求symbol的地址。

(3) 数据管理（Data Management）：

数据传输通过DOCA CC透明维护。指针会直接交换，OpenMP运行时可按需使用这些指针。

(4) 目标区域运行（Run Target Region）：

OpenMP运行时请求入口地址（根据symbol名称提供）以携带arguments（作为BlueField指针）运行。

该信息再次通过DOCA CC传输至OpenMP DOCA服务，由后者相应地执行代码。

3.OpenMP DOCA 服务

相应地，设备端的OpenMP DOCA 服务实现了 OpenMP BlueField 插件中所实现方法的服务器版本。

(1)二进制加载（Load Binary）：

设备通过DOCA通信通道（CC）接收二进制镜像，将其保存为临时文件，并使用`dlopen`例程作为动态库打开。通过`dlsym`例程检查所需symbol的对应地址，这些地址会通过DOCA CC返回给主机。 

(2)数据管理（Data Management）：

数据管理通过DOCA CC透明处理。

设备分配内存后，将`malloc`例程返回的指针传回主机，主机后续用该指针提交和/或检索数据，同样的指针也用于释放内存分配。

(3) 目标区域运行（Run Target Region）：

通过BlueField插件将`dlsym`提供的地址传递给OpenMP运行时，以指定待执行的目标区域，同时传输参数。

此处使用名为`libffi`的底层外部函数接口库来运行目标区域：由于DOCA OpenMP服务在编译时无法预知参数，需借助`ffi_prep_cif`和`ffi_call`方法在运行时执行代码。

`ffi_prep_cif`根据数据大小、类型和对齐方式准备`ffi_cif`结构，随后`ffi_call`利用该结构在DPU上运行指定函数。

五、评估

评估实验使用了来自HPC-AI咨询委员会专业知识网络的两个支持BlueField的集群。

一个是Thor集群：

集群有36个节点。

每个节点配备双插槽Intel Xeon 16核CPU E5-2697A V4（2.60 GHz）、256 GB DDR4内存，以及NVIDIA BlueField-3 NDR 200 Gb/s DPU（BF3）。

BF3配备16个ARMv8.2+ A78核心和16 GB DDR5内存。

另一个是Jupiter集群：

集群有32个节点。

节点配备双插槽Intel Xeon 10核CPU E5-2680 V2（2.80 GHz）、64 GB DDR3内存、NVIDIA K40 GPU，以及BlueField-2 HDR100 100 Gb/s DPU（BF2）。

BF2包含8个ARMv8 A72核心和16 GB DDR4内存

在软件栈方面，实验使用DOCA 2.0.2、LLVM 14.0.6和OpenMP 5.0，基于SPEC ACCEL套件。

SPEC ACCEL提供了一组测试来评估OpenMP卸载API的性能。

表1总结了评估中使用的微基准测试，并提供了有关其数据传输的信息。

图片

由于所呈现的框架是为Clang编译器开发的，因此现在只关注基于C的代码。预计Flang编译器对Fortran的支持将很快发布。

请注意，这些基准测试最初是针对基于GPU的应用程序设计的。由于GPU在大规模并行应用中具有计算效率优势，因此这些基准测试利用了OpenMP的`teams distribute`结构的能力。而DPU由少数ARM核心组成。因此，移除这些结构有助于代码编译成更适合DPU的高效二进制文件。

此外，由于ARM架构支持SIMD指令，因此利用OpenMP的`simd`结构可进一步提升DPU的性能。诸如`parallel for`之类的结构则启用了多核能力。这些结构的使用决定了处理器的利用方式，而基准测试则决定目标代码是在单核还是多核上运行。

首先，针对OpenMP的DPU卸载功能在不同BlueField设备上进行了评估，特别是在BF2和BF3机器中。图2对比了执行时间，结果显示BF3如预期般优于BF2，根据应用场景不同，性能优势在3.6倍至8.5倍之间。

图片

接下来评估ODOS解决方案与MPI基线相比的表现。

作者们在SPEC ACCEL 中实现了多个微基准测试的 MPI 版本，其中原始的卸载内核将在 MPI 进程（rank）上下文中的 DPU 上执行。在DPU中的进程与主机中的进程进行通信，并按照第二节第2小节(2)MPI所述的编程模型，像使用OpenMP卸载那样执行内核。

Listing 1和Listing 2中展示的代码片段演示了使用MPI和OpenMP的基准测试的基本结构，包括将数据发送到设备、在设备上执行计算以及在主机上接收结果。

通过对这些方法进行清晰对比可以看出，OpenMP提供的编程范式显著更简单直接。

图片

图片

图3对比了MPI和OpenMP微基准测试版本的执行时间，可以看到性能上的细微差异。

图片

由于底层硬件相同，这些微小差异的原因大致有两点：编译器和数据传输管理。

一方面，OpenMP编译器能够将用于配置执行的输入参数打包到二进制文件中。若有需要，这些参数仅需一次传输即可发送。相反，在MPI版本中，这些参数需要分别传输到各个进程（rank）。因此，OpenMP的性能表现略优。

另一方面，MPI和OpenMP中不同的通信机制可能导致不同的传输行为。在这方面，表2包含了微基准测试的通信/计算时间及比率。

图片

除了pep之外，微基准测试的MPI实现版本在执行时间上略优于对应的OpenMP版本。尽管所有应用均属于计算密集型，但polbm中的通信时间占总执行时间的7%，这也解释了两个版本之间最大的时间差异。

为此，接下来将对主机与设备之间的通信进行深入分析，研究其带宽和延迟特性，以明确运行时的网络管理所扮演的角色。

用于分析带宽和时延的基准测试基于OSU微基准测试（OMB）。OMB是一套评估MPI性能的基准测试套件，我们使用点对点带宽和时延测试来衡量MPI性能。

为了提供公平的比较，我们对OMB进行了适配，使其适用于CUDA和DOCA。

对于CUDA，消息通过`cudaMemcpyAsync`发送；

对于DOCA，使用`doca_comm_channel_ep_sendto`

（另一端使用`doca_comm_channel_ep_recvfrom`）。

OMB将大于8KiB的消息视为大消息，遵循OMB的设计理念，这些基准测试的结构如下：

(1)热身阶段（Warming up）：

带宽测试 ：小size消息执行10次迭代，大size消息执行2次迭代。

时延测试 ：小size消息执行1000次迭代，大size消息执行100次迭代。

(2) 评估阶段（Evaluation）

带宽测试：小size消息执行90次迭代，大size消息执行8次迭代。

时延测试：小size消息执行9000次迭代，大size消息执行900次迭代。

(3)同步阶段（Synchronization）：

反向回传一条消息；却如有可能，显式执行同步操作：

MPI使用`MPI_Barrier`，OpenMP使用`taskwait`结构，CUDA使用`cudaStreamSynchronize`，

DOCA则通过轮询事件（对从`doca_comm_channel_ep_get_event_channel`获取的文件描述符进行事件轮询）。

请注意，CUDA实验是在巴塞罗那超级计算中心（BSC）的CTE-Power集群上进行的。该集群配备IBM Power9处理器和NVIDIA V100 GPU，使用的CUDA版本为10.1。

图4和图5分别展示了不同执行环境下不同消息大小的带宽和延迟情况。

图片

图片

在消息大小不超过64 KiB时，OpenMP DPU在带宽和延迟方面的性能均优于OpenMP GPU。

然而，一旦达到这一阈值，ODOS中会启用某些不可避免的同步原语，导致OpenMP DPU的性能相比OpenMP GPU相对较低。

OpenMP DPU的通信基于DOCA，而OpenMP GPU的通信基于CUDA。

在这方面，理想情况下，期望是两种OpenMP实现相对于其底层低级编程模型表现出相似的行为，当然，绝不会优于底层模型。

因此，对于小size消息，OpenMP实现的带宽明显低于其底层低级模型。在中等size消息中，性能会出现一系列波动，直到在较大size时趋于一致。我们发现，对于大size消息，报告的带宽下降是因为在这些size下固定内存所需的处理时间。

在DOCA中，中等size消息（2–64 KiB）的传输速度会变慢，因为通过单次DOCA CC调用所能发送的最大消息size为2 KiB。因此，对于更大size的消息，处理器需要对其进行分片处理。

在CUDA和OpenMP GPU的运行中，当有效载荷超过4 MiB后，带宽会下降，这体现了大消息的处理时间问题。对于基于DOCA的执行，当消息大小超过64 KiB时，需要反向发送同步消息以保持各尺寸消息间的同步性，因此带宽在该节点之后开始下降。

关于延迟方面，OpenMP-SDK 组合在趋于一致之前表现出更稳定的特性。该实验旨在证明 OpenMP DPU 具备预期的性能表现。

六、结论和未来工作

这篇文章基于LLVM和BlueField DOCA SDK，提出了首个针对DPU网络协处理器的OpenMP卸载解决方案。

现有的DPU网络协处理器解决方案要么（1）采用底层设备编程，要么（2）通过部署在差异极大架构中执行的进程来实现非自然的MPI使用，而这篇文章为业界提供了一种更简单、更自然的方法。

BlueField 3设备的最新问世——其性能远优于前代产品——结合我们的编程方案，有望为更广泛、更大量的研究和生产成果打开大门。

HPC应用可从DPU设备中获益，将部分负载卸载至这些设备。例如，在训练深度神经网络时，数据增强或验证阶段可卸载到功耗较低的加速器（如DPU）。反过来，在大型分布式多物理场模拟中，可卸载光晕交换操作至DPU，由它负责在相邻节点间通信和计算光晕（halo）。为此，作者们已着手进行MPI集成工作，即在卸载任务中提供对MPI调用的支持。

ODOS软件可从以下网址下载：

https://www.bsc.es/discover-bsc/organisation/scientific-structure/acceleratorsand-communications-hpc/team-software