【论文阅读】dpBento：用于数据处理的 DPU 基准测试

霞姐聊IT

发布于 2025-06-19 10:25:22

2150

今天我们来看一篇由多伦多大学、微软亚洲研究院、新加坡国立大学的研究人员2025年发表的文章《dpBento: Benchmarking DPUs for Data Processing》。

原文可从以下地址下载：https://arxiv.org/pdf/2504.05536

一段话总结：

研究人员提出了 dpBento 这一衡量DPU数据处理（数据库和KV存储等）性能的基准测试套件，它提供了可扩展的任务抽象，可在此基础上集成并自动化各种性能测试。

研究人员还借助了dpBento实现了一组微基准测试，用于测量DPU的CPU、内存、网络和存储性能，以及谓词下推和索引卸载情况和完整DBMS的性能。

实验结果揭示NVIDIA和MARVELL两家三款不同 DPU 资源和不同 DPU 的性能特征，以及将各种数据库相关操作和模块卸载到 DPU 的性能影响，为 DPU在数据处理中的应用提供了有价值的见解。

一、现状和目标

云计算中数据处理workloads（如数据库、KV 存储）正在增长，但CPU 计算效率因硬件缩放定律放缓而难以维持。同时分离式部署使得网络通信成为主要性能瓶颈。同时存储和网络设备速度提升也在导致CPU开销的增加。

DPU 作为基于 SoC 的 SmartNIC，具备节能 CPU 核心、适中内存、ASIC 加速器、高速网络接口、PCIe接口等资源，可卸载 CPU 密集型任务，提升数据移动性能。

那么DPU能否用于云数据处理呢？现有研究工作表明，DPU卸载在数据库和KV存储中有切实优势。

但现有研究工作仅探索了有限的DPU能力，例如用户空间网络、板载DRAM和节能CPU。仅限于少数操作类型，如远程存储读取、索引和shuffling。

另一类研究工作是针对特定厂商的DPU进行特定任务的基准测试，但都不涉及数据处理工作负载，例如：

DPU-bench可衡量DPU之间MPI通信的效率。

DPUBench为NVIDIA BlueField-2 DPU提供基准测试套件。

Liu和Wei评估了BF-2的RDMA和计算效率。

同时这两类研究工作都只针对一种DPU，而忽略了DPU设备的多样性，比如市面上的DPU有：NVIDIA BlueField、AMD Pensando、Intel IPU、Marvell OCTEON和AWS Nitro等多种产品。

因此，需要一个更广泛的数据处理工作负载DPU基准测试。该基准测试应包括不同的数据处理任务，使用DPU上的不同硬件资源，并可移植到不同的DPU设备。基准测试结果可以提供见解，帮助确定哪些数据处理工作负载适合DPU卸载，以及是卸载基本指令、数据库组件还是端到端系统。

dpBento是为了满足这一需求提出的基准测试框架。用于自动化生成、执行和报告DPU上的数据处理性能测量测试。这篇文章将使用dpBento展示多个量产DPU的基准测试结果。

1.dpBento基准测试框架：

dpBento为指定DPU上的大规模测量测试工作流程提供了任务抽象：准备环境、根据用户配置执行测试、基于感兴趣的指标生成信息丰富的报告，最后通过消除测量的任何影响来清理DPU。

基于这一通用抽象研究人员开发了内置测试，包括：

（1）与数据处理效率密切相关的基本操作，包括测量计算、内存、存储和网络性能的任务；

（2）验证DPU优势的云数据库系统模块，包括谓词下推和索引卸载；

（3）使用流行轻量级数据库管理系统（DuckDB）的宏观数据库工作负载。

一个任务可以可配置为生成不同的测试，例如，计算任务可通过参数化来测试数据系统中常见的计算操作：算术或字符串操作。

用户只需创建一个配置文件即可使用dpBento。配置文件称之为测量盒（measurement box）或简称“盒”。对于每次测量，该盒定义了任务、任务参数以及感兴趣的性能指标。例如，用户可以声明一个盒来测量读取内存对象的延迟和带谓词下推的表扫描吞吐量。

给定盒配置后，dpBento会自动生成测试、执行每个任务的工作流程、收集测量结果，并最终向用户呈现测试结果。这将各种数据处理任务的DPU性能测试统一到单个框架中。

dpBento的一个主要目标是可扩展性。

DPU的加速器和特定供应商的产品相关，例如，NVIDIA BF-2配备了压缩ASIC，而BF-3或Marvell OCTEON 10则没有这种加速器；用于对加速器进行编程的SDK也是特定于供应商的，例如BlueField的是DOCA，OCTEON是基础Linux SDK的扩展。

为了衡量硬件加速的效果并支持临时数据处理任务（例如用户考虑卸载到DPU的特定数据系统模块），dpBento允许使用插件任务。这些任务由用户按照任务抽象进行实现，并放入框架中。

在执行测量时，用户可以在盒配置中的插件任务中声明测试。然后，dpBento将生成并执行这些测试。

作为dpBento模块化设计的一个优势，插件使在DPU上进行更广泛的数据处理基准测试成为可能。

2.量产DPU的基准测试：

借助dpBento，研究人员对主流DPU在数据处理工作负载中的表现进行了全面评估。dpBento的内置任务覆盖了从基础操作、数据库系统模块到完整DBMS的各类工作负载。

研究人员通过运行这些任务，对NVIDIA（BlueField-2和BlueField-3）和Marvell（OCTEON TX2）的DPU进行了测试。

此外，研究人员还实现了插件任务，以评估这些DPU上硬件加速器对计算密集型操作的提升效果，以及用户空间网络带来的优势。

这篇文章对实验结果进行了分析和呈现。

对于可测试多个DPU的场景（如内置的基础操作测试），文章会对比这些DPU与主机的测试结果；

而针对仅适用于特定DPU的插件任务，则评估DPU特有功能带来的优势。

分析揭示了DPU卸载在数据处理中的关键洞察：例如：

尽管DPU的CPU核心在通用应用中性能较弱，但在特定操作中表现优于主机CPU；

DPU硬件加速器虽能实现极高吞吐量，但需以高延迟为代价；

相较于在DPU上运行完整DBMS，卸载数据库子模块更能充分发挥DPU性能优势。

本研究的贡献如下：

- 提出了dpBento，这是一个以DPU为中心、用于衡量数据处理任务的统一基准测试套件

-对近期量产的DPU进行基准测试。

-呈现基准测试结果，并深入分析计算与I/O效率、云数据库模块网络内卸载的优势，以及在DPU上运行完整DBMS的开销。

二、DPU相关背景

1.DPU

DPU 是片上系统（SoC）架构，支持数据路径的自定义与优化的智能网卡。目标数据路径操作涵盖数据中心网络中的数据包处理和分离式存储协议。

DPU可通过其支持的硬件资源来定义（见图1）。

(1)作为网卡，DPU通常具备先进的网络速度，可实现数百Gbps的带宽，以支持DPU之间的快速数据传输。

(2)为提供便捷的编程和访问能力，DPU配备了板载CPU和标准操作系统（如Linux）。出于能效考虑，其CPU采用低功耗架构（如Arm或MIPS）。

(3)为加速压缩、加密和正则表达式（RegEx）匹配等计算密集型的数据路径任务，DPU将这些任务固化为板载加速器，以实现超高性能和能效。

(4)DPU还配备中等容量的DDR内存（通常为8GB至32GB），用于存储卸载应用的工作集。

(5)DPU上的PCIe交换机使其能够访问外部系统资源（如主机内存及SSD、GPU等对等PCIe设备）。

(6)尽管本地辅助存储（如SSD）并非低延迟高吞吐量数据路径应用的必需组件，但DPU仍需要其来安装固件和操作系统。

与基于ASIC和FPGA的智能网卡相比，DPU凭借板载CPU提供通用可编程能力，并通过硬件加速器实现更高的计算性能和能效。

鉴于当前云基础设施的发展趋势（如虚拟化、高性能IO和资源分离），DPU正成为将主机功能卸载的主流解决方案，以降低总体拥有成本（TCO）并提升数据路径效率。近期研究表明，将特定数据处理任务卸载至DPU已取得显著成效。

2.DPU的多样性

DPU 卸载在数据处理中一个关键的考量因素是 DPU 的多样性，这体现在以下几个方面。

(1)资源各异。

DPU的片上系统（SoC）拥有通用和专用计算资源、内存、存储，以及与网络和主机上其他资源的互连功能。所有这些资源都可被数据处理系统利用，但与主机服务器相比，它们呈现出不同的性能特性。

(2)厂商众多。

目前已量产的商用DPU包括：NVIDIA BlueField、Marvell OCTEON、Intel IPU、AMD Pensando、Broadcom Stingray、Kalray MPPA、AWS Nitro、阿里云CIPU和微软Fungible，且大多数云服务提供商正在部署这些产品。

图1展示了NVIDIA BlueField-3和Marvell OCTEON TX2的规格——这是我们在本研究中进行基准测试的两款先进DPU。

尽管它们遵循相同的高层架构，但网络接口和硬件加速器等详细硬件配置存在显著差异。

(3)DPU的软件开发工具包（SDK）通常具有厂商特异性。

例如，NVIDIA提供DOCA SDK用于对BlueField DPU进行编程，而Marvell则为OCTEON提供更标准的Linux工具链和数据平面开发套件（DPDK）。

(4)代际差异。

即使是同一厂商的DPU，不同代际的配置也可能不同。例如，从BlueField-2到BlueField-3，不仅CPU、内存、PCIe和网卡得到了升级，硬件加速器的配置也发生了变化。

为最先进的DPU创建并运行通用基准测试套件，是理解不同DPU资源及不同DPU对云数据处理影响的关键。

三、DPBENTO框架

dpBento是一个以DPU为中心的基准测试框架。它有四个主要目标：

（1）可扩展性。能对用于数据处理的不同DPU资源进行压力测试；

（2）可定制性。用户能通过选择性测试专注于特定的数据处理方面；

（3）可移植性。使其能够测量不同的DPU；

（4）就绪性。其现成的存储库已包含一系列测试，用户可运行这些测试来对其DPU进行基准测试。

本节将详细介绍可扩展的抽象、可定制的测量、可移植的工作流程，以及deBento提供的微基准测试和系统模块测试，以评估广泛的数据处理操作和工作负载。

1.任务抽象

在dpBento中，数据处理工作负载被实现为任务。它可以是内存读取等基础操作，也可以是谓词下推等粗粒度的数据库模块。

任务通过性能测试进行参数化，以利用感兴趣的指标评估DPU片上系统（SoC），并按以下四个步骤执行。

(1)准备。在DPU上执行性能测试可能需要安装外部库和工具包作为依赖项、下载开源数据集以及设置目录。此步骤用于正确准备DPU环境。

(2)运行。通过指定测试的具体参数（例如内存随机读取）和目标性能指标（例如平均延迟），此步骤将执行性能测试并生成包含测量结果的日志。

(3)报告。单个测试的结果可临时缓存于日志中。此步骤用于处理中间日志，以生成经过整理、格式化并最终呈现给用户的报告。

(4)清理。对DPU进行基准测试不应修改其状态——不期望也不允许产生永久性影响。此步骤用于清理任务中生成的所有目录、文件以及软件和系统配置，使DPU恢复到任务执行前的状态。

这些步骤构成了dpBento的接口。

为了实现一个任务，用户需将每个步骤的逻辑作为Python脚本提供，框架将按指定配置并执行。

基于此抽象，研究人员已将广泛的数据处理性能测试实现为任务，包括微基准测试、云数据库模块和完整的DBMS。

2.可扩展性

用户可以自定义DPU性能测试并扩展基准测试套件。

首先，性能测量作业可以由支持的任务中自定义的测试集组成，这被称之为测量盒（measurement box）或“盒”。

具体而言，dpBento的任务可提供一组任务特定参数，用户可通过指定这些参数来实例化测试。

例如，内存任务允许用户指定想要测量DPU内存层级的哪个级别（即L1-L3或DRAM），以及测量吞吐量还是延迟。

用户在JSON文件中声明一个“盒”，其中指定要运行的任务、每个任务的参数以及要测量的指标。

图2展示了一个“盒”示例，该示例指定了一个作业，用于测量：（1）使用递增数量的CPU核心时，DPU上TCP网络通信的中位数和尾部延迟及带宽；（2）在指定核心利用率下将谓词下推到DPU时扫描数据库元组的吞吐量。

此外，dpBento允许用户以插件形式创建新任务，这得益于其可扩展的任务抽象设计。

用户能够实现用于访问厂商特定DPU功能（如硬件加速器）的插件。

若要向dpBento添加插件，用户可在dpBento存储库中创建专用目录，并在该目录下通过四个对应的Python脚本来实例化任务抽象。这些脚本是任意性能测试实现（即使用任意语言并包含任意依赖项）的shell程序。

插件一旦添加，即可包含在“测量盒”（box）中。

dpBento中的内置任务可移植到任何提供标准Linux发行版和工具链的DPU片上系统（SoC），这几乎适用于所有DPU。

另一方面，插件依赖于特殊硬件和/或专有软件，因此不具备可移植性。

3.工作流

图3展示了dpBento的工作流程。

它首先解析每个“测量盒”的JSON文件，以确定该作业中需要执行的所有任务。

对于每个任务，它会对参数进行笛卡尔积组合，生成所有可能的测试用例组合（即测试）。dpBento不会将参数与指标进行组合，因为单个测试可能会生成多个指标的结果——例如，一个网络测试可以同时生成中位数延迟和99%分位延迟。

在执行任何测试之前：

❶ dpBento会调用准备脚本，为当前任务中的所有测试初始化DPU环境，以避免在测试之间重复准备工作。然后，

❷ 参数组合会与指标一起按顺序传递给运行脚本，以执行测试。每个测试可以单独生成日志来缓存中间测量结果。在所有测试执行完毕后，

❸ 会调用报告脚本处理中间结果，并向用户生成最终报告。

在dpBento中，性能测试完全自动化。用户只需声明“测量盒”（boxes），上述所有步骤均由框架透明管理。

由于多个“测量盒”可能涉及相同任务，且环境准备可能耗时，因此dpBento不会在每个任务执行后立即调用清理脚本。相反，

❹ 系统提供命令行让用户显式清理DPU。

4.微基准测试

研究人员已利用dpBento的任务抽象机制，将一系列数据处理工作负载实现为其内置任务，如表1所示。

首先介绍使用基础操作来评估DPU计算和I/O性能的微基准测试。

(1)计算

CPU微基准测试聚焦于基本类型的基础操作，具体而言，包括:

基本数值类型的算术运算（这些运算在数据处理中大量使用，例如用于评估谓词和表达式），以及字符串函数（如比较、搜索和操作）。

尽管数据库系统中十进制类型的使用频率高于浮点数，但当今典型的CPU通常不提供对十进制的硬件支持，却支持整数和浮点数运算。

十进制类型的使用通常依赖库或语言特性，其优化性能水平各异，无法直接反映硬件能力；此外，定点十进制类型通常表示为按10的幂缩放的整数。

随着向量数据库的兴起，由于涉及相似性搜索算法，所以预计这些系统将更频繁地使用浮点数。结合量化技术，使用更小数据类型（8位、16位等）进行计算变得尤为重要。

因此，研究人员在DPU上对不同宽度的整数和浮点数进行基准测试。

研究人员评估单个物理DPU核心上算术运算（加法、减法、乘法和除法）的吞吐量（以每秒操作数为单位）。

该任务通过在寄存器上重复执行相应指令来强调原始计算能力，排除CPU缓存和主内存的影响。

用户可以参数化测试的数据类型（如int8、int128或float64）和操作（加、减、乘或除）。

字符串操作（如比较和子串匹配）在查询谓词中很常见，直接影响扫描和过滤性能。

研究人员对小（10字节）、中（64字节和256字节）和大（1KB）字符串进行基准测试，以模拟不同的应用场景，并以每秒操作数衡量性能。

除了内置的CPU测试外，研究人员还实现了一系列插件（即更高级别的计算密集型任务），用于评估DPU上硬件加速器的性能优势。

为了与基础类型测试区分，这些插件将被称为“可优化任务”——它们可通过向量化（SIMD）指令、多核并行处理以及DPU硬件加速器进一步优化。

dpBento纳入了三个此类任务：采用DEFLATE算法的压缩、相应的解压缩，以及正则表达式（RegEx）匹配。

这些任务在云数据系统的数据路径中频繁被调用。

探索可优化任务能了解不同计算优化层级（尤其是当今数据系统尚未充分利用的硬件加速器）带来的性能提升。

(2)内存

内存微基准测试任务用于评估访问内存对象的速度。

具体来说，会创建一个指定大小的内存缓冲区，然后根据指定的访问模式（随机访问或顺序访问）在缓冲区中访问（读取或写入）指针大小的数据，最后测量吞吐量（每秒完成的访问次数）或带宽（GB/s）。

除了这些参数，用户还可以配置并行发出内存访问请求的线程数量，以更好地利用内存带宽。dpBento采用sysbench作为测试驱动程序，这是一个可脚本化的多线程基准测试工具。当在执行DPU基准测试时，为该任务声明的参数将传递给sysbench以生成内存测试。

(3)存储

存储微基准测试通过一组广泛的参数生成异步磁盘I/O活动，以测量DPU本地存储设备的性能。

其核心是一个功能全面的存储测试工具包。

具体而言，它会在指定磁盘上初始化一个包含随机内容的文件，支持发起文件读写操作，并测量这些操作的详细延迟和吞吐量统计数据。

为实现高效的辅助存储访问，该工具支持通过io_uring或libaio实现异步I/O。

实验表明，该存储基准测试工具可使所有被测DPU的本地磁盘以及主机NVMe SSD的带宽达到饱和。

用户可指定I/O类型（读或写）、访问粒度（以字节为单位）、队列深度（未完成文件请求的数量）和并发度（并行发起I/O的线程数），还能从吞吐量、平均延迟及不同百分位的尾部延迟中选择关注的指标。

(4)网络

为评估网络传输性能，dpBento包含一项基准测试任务，该任务使用Linux套接字测量TCP（数据系统中最常用的传输协议）的速度。

具体来说，该任务会在源端自动创建两个TCP端点：一个发送指定大小的消息，另一个作为目的端接收每条消息并将其回传给源端。

源端和目的端可以是DPU，也可以是用户提供IP地址的主机（本地主机或远程机器）。

此任务测量消息传输的端到端延迟和吞吐量。

用户可通过以下参数定制测试：消息大小（以字节为单位）、队列深度（TCP连接中未完成消息的数量）和并发度（TCP连接数，每个连接由客户端/服务器线程处理）。

5.云数据库模块

先前的研究已证明将云数据库组件卸载到DPU具有两大普遍优势：近数据处理（在更靠近数据的位置执行操作，以最小化数据移动开销），以及为主机提供额外的处理能力。

dpBento纳入了两项卸载云数据库模块的任务，以分别探索这些优势。

（1）谓词下推

此任务针对分布式存储架构，其中SQL查询由计算服务器上的数据库引擎执行，而数据库文件存储在存储服务器上。

存储服务器配备DPU，计算服务器通过100 Gbps链路连接至该DPU，并在扫描数据库元组时利用其进行谓词下推。

基准方案：在计算服务器上运行DuckDB，数据库文件通过网络从存储服务器获取以执行扫描。

谓词下推方案：在DPU上执行数据库管理系统的扫描模块，仅将符合条件的元组返回至计算服务器。

测试将扫描TPC-H基准测试中的lineitem表。

如表1所示，用户可以配置表的规模、谓词的选择性以及在DPU上生成的线程数量。衡量指标为每秒扫描的元组数量。

（2）索引卸载

dpBento卸载到DPU的第二个模块是索引。

将数据库服务器上配备的DPU用作主机的协处理器，以部分处理索引请求。

在主机和DPU之间对B+树进行范围分区，从而使DPU处理请求能够提升整体索引性能。该实现改编自支持MVCC并发的LMDB。

dpBento使用YCSB基准测试作为工作负载。

dpBento的用户可以配置索引大小（键值记录大小和数量）、操作类型（读/写）、访问模式（均匀或倾斜）、卸载的索引比例，以及执行卸载请求的DPU线程数量。

此任务测量索引吞吐量（每秒完成的操作数）。

6.完整的DBMS

为支持系统级性能测试并量化在低功耗DPU核心上运行端到端系统的性能衰减，dpBento纳入了一项基于DuckDB的完整系统评估任务。

DuckDB是一款功能完备的轻量级关系型数据库管理系统，因此更适合DPU。

其目标针对嵌入式数据分析，通过避免任何外部依赖来优化部署的简便性。

整个系统可编译为一个头文件和一个库，便于集成到应用程序中。

在应用进程内运行时，它可最大限度减少应用与数据库管理系统之间的数据移动。

dpBento的任务会拉取DuckDB的最新版本（当前为v1.1.3），并在准备阶段从源代码进行编译。它会根据指定的规模因子将TPC-H设置为工作负载。

用户还可以参数化要运行的TPC-H查询、在DuckDB中创建的线程数量以及执行模式（冷模式，即查询从未在DPU上执行过；或热模式，即查询已执行过几次以预热内存缓冲区）。性能指标是查询执行时间。

四、待基准测试的硬件

借助dpBento，研究人员对近期几款量产的DPU进行了基准测试。本节将介绍这些DPU的硬件配置，以及用作基准来与DPU数据处理性能进行对比的主机设备。

1.NVIDIA BlueField

研究人员评估了两代NVIDIA BlueField DPU：BlueField-2（BF-2）及其后继型号BlueField-3（BF-3），这两款产品均已量产。

图1展示了测试平台中这两款DPU的详细信息。

BF-2搭载Arm A72 CPU（64位），包含8个核心，主频2.5 GHz。

每两个核心共享1 MB L2缓存，所有核心共享6 MB L3缓存。

板载16 GB DDR4内存作为DPU主内存，并配备多种硬件加速器（包括压缩、解压缩和正则表达式匹配加速器）。

ConnectX-6网络接口卡提供100 Gbps网络带宽，主板通过PCIe 4.0与主机连接。

BF-2还内置直接焊接在主板上的eMMC闪存设备。

BF-3几乎在所有方面都是BF-2的升级版本：

Arm CPU升级为A78，配备16个核心，时钟频率高达3.0 GHz。

L2缓存增加到6 MB，L3缓存增加到16 MB。

板载内存升级至32 GB DDR5。

网络接口升级为ConnectX-7，提供400 Gbps带宽，与主机的接口也提升至PCIe 5.0。

直接连接的本地存储也更新为160 GB NVMe SSD。

值得注意的是，压缩引擎被移除，这使得硬件加速器的配置有所不同。

2. Marvell OCTEON

测试平台中还包括一款Marvell OCTEON TX2 DPU，详情如图1所示。

与BF-2类似，它搭载Arm A72 CPU，但核心数量更多（24个核心，主频2.2 GHz），每两个核心共享1 MB L2缓存，所有核心共享14 MB L3缓存。

该DPU配备32 GB板载DDR4内存，提供100 Gbps以太网接口及用于连接主机的PCIe 3.0接口。

其硬件加速器与BlueField不同，主要用于网络安全和数据包处理。

和BF-2一样，OCTEON配备64 GB eMMC本地存储。

3.主机设备

研究人员在一台近期组装的主机服务器上执行了同一组dpBento任务，该服务器代表了当前最先进的主机配置。

具体而言，该服务器配备两颗AMD EPYC 9254 24核CPU，主频2.9 GHz，总计48核（96线程），拥有48 MB L2缓存和256 MB L3缓存。

服务器的主内存为128 GB DDR5，持久化存储包括两块960 GB NVMe SSD。

将基准测试结果与主机上的结果进行对比，有助于更好地解读DPU的数据处理性能。

五、计算效率

首先呈现三个DPU和主机上计算与内存任务的基准测试结果，详细发现如下。

1.基本操作

下表展示了用于对DPU进行基本计算任务基准测试的测试参数：我们对不同大小的整数和浮点数（int8、fp64和int128）执行所有算术运算。这些类型和运算在不同的数据系统中很常见，例如数据库和机器学习模型

详细的基准测试结果如图4所示，涵盖整数和浮点数运算。

首先，图4a展示了8位整数操作的性能。

加法（add）和减法（sub）：主机AMD CPU相比DPU的Arm核心展现出显著的性能优势，达到每秒65亿次操作（ops/s）——比DPU高出5.5倍。

乘法（mul）和除法（div）：尽管四个CPU的吞吐量均如预期出现下降，但主机CPU与DPU的CPU的性能衰减程度有所不同。

具体而言，主机CPU在int8乘法运算时的吞吐量较加法下降了58%，这一降幅高于OCTEON（49%），更明显高于BF-2（14%）和BF-3（19%）。

不过，主机CPU的性能仍比表现最佳的DPU（BF-3）高出2倍。对于除法运算，主机CPU的性能进一步下降（较乘法降低70%）。

OCTEON的Arm核心呈现相同趋势：吞吐量显著下降80%。BF-2和BF-3的表现相对更好，乘法到除法的吞吐量降幅较低（分别为36%和64%）。

如图4b所示，在int128运算中，可以观察到整体性能趋势类似——主机仍以较大优势保持最佳性能，且所有CPU的乘法和除法吞吐量相比加法和减法均有所下降。

随着操作数大小增加，所有平台上的所有操作吞吐量相应降低，而DPU的整体降幅百分比更大。

具体而言，从int8到int128，主机操作的吞吐量平均下降34%，而OCTEON、BF-2和BF-3的降幅分别为76%、73%和63%。

这种差异在乘法和除法中尤为显著，例如DPU的吞吐量降幅为63%-77%，而主机仅为12%，此时主机速度比性能最佳的DPU快4.7倍（int8时为1.7倍）。

这些结果表明，DPU更擅长处理较小的操作数。

如图4c所示，DPU在双精度浮点数（fp64）运算中的性能表现与整数运算截然不同。主机CPU在整数计算中显著的性能优势几乎完全消失：

两款BlueField DPU在加法、减法和乘法运算中反超主机CPU，其中BF-3的平均性能领先幅度超过50%。

与整数运算性能相比，OCTEON在浮点计算中也展现出更强的竞争力，尽管仍与BlueField系列DPU和主机CPU存在明显差距。

值得注意的是，主机CPU在除法运算中仍保持优势，但其领先幅度远小于整数运算场景。DPU在浮点运算中的高性能可归因于Arm架构的硬件支持。

三种典型的字符串操作进行的基准测试：比较（strcmp）、简单操作（strcat）和复杂转换（strcfrm）的结果如图5所示。

主机CPU在所有类别中均具有更高的吞吐量，但主机CPU与DPU之间的性能差距因类别而异。

对于strcmp，字符串大小对DPU和主机CPU的影响不大，主机CPU的性能接近最强DPU（BF-3）的2倍。

对于strcat，主机仍具有绝对性能优势，但相对于DPU的领先优势较小，尤其是对于小字符串：BF-3在10字节字符串时达到主机CPU性能的68%，在1024字节字符串时降至39%。

strxfrm则呈现出不同的情况——随着字符串大小的增加，主机CPU的优势差距扩大，并且BF-3相对于其他DPU的领先优势比字符串搜索更为显著。然而，主机CPU的性能仍比BF-3高出两倍以上，且随着字符串大小的增加，差距进一步扩大，在OCTEON上的吞吐量差距达到7倍以上。

基于这些结果，得出发现如下：

DPU在处理较小操作数时速度更快，甚至在浮点处理方面性能可超越主机。

对于字符串操作，DPU更适合处理较为简单的操作。

2.硬件加速

为研究 DPU 硬件加速的优势，并将其性能特性与现有 CPU 技术进行对比，研究人员针对 NVIDIA DPU 运行了三项插件任务。

在每项任务中，研究人员使用 DOCA来访问BF-2 /BF-3的硬件加速器。

研究人员还实现了一个可利用 SIMD和多线程的软件版本，用于在 CPU 上运行。

首先考察使用DEFLATE的压缩情况，该算法是数据库系统中最常用的压缩算法之一。研究人员使用此算法压缩从指定大小的TPC-H订单表生成的字符串。

BF-2为此压缩提供了硬件加速器。

除了BF-2和主机的单核性能外，研究人员还将BF-2的硬件加速与多线程（使用所有可用核心）和SIMD这两种可提升这两款CPU性能的技术进行了对比。图6a展示了不同硬件技术的压缩速度表现。

根据实验结果会发现，DPU的硬件加速并非始终最优：在BF-2上调用硬件加速器时存在固定的启动开销。对于小于100 KB的数据，硬件卸载的性能低于主机和BF-2 CPU的处理性能。然而，当数据规模增大（≥1 MB）时，BF-2的硬件卸载展现出显著优势，其吞吐量超过主机CPU的多线程执行（压缩512 MB数据时速度快4.9倍）。值得注意的是，对于极小数据量，多线程执行也因线程开销而无法带来性能提升。

BF-2和BF-3均支持解压缩加速，基准测试结果如图6b所示。

与压缩结果类似，BlueField系列的硬件加速器存在较高的启动延迟，这表现为在较小负载规模（小于1MB）下吞吐量较低，但在处理较大数据时效率显著提升：当压缩256MB数据时，BF-2解压缩加速器的速度比主机CPU/其板载多线程CPU快13倍/21倍。

此外，BF-3的加速器启动延迟高于BF-2，但随着数据规模增长至数百MB，其速度会超过上一代产品。

另一个发现是，对于解压缩任务，主机与板载CPU之间的性能差距相对较小，尤其是在多线程执行时，这很可能是由于DEFLATE算法的特性——解码过程会序列化数据访问，因此难以并行化。

最后一项可优化任务是正则表达式（RegEx）匹配，BF-2和BF-3均为此提供硬件加速。此任务中匹配属于TPC-H查询13的模式，具体生成的模式类似“%special%requests%”。

图6c展示了字符串数据集大小变化的结果。

首先，BF-2和BF-3的硬件加速性能相同，在小数据量时优于使用多线程执行的性能。然而，单线程SIMD实现的性能要优越得多。随着数据量增加，硬件加速器的性能可与多线程执行（使用所有可用CPU核心）相当。但最终多线程执行的扩展性更好：在256 MB数据量下，主机CPU和BF-3 CPU的性能分别比两个DPU上的RegEx加速器快3倍和1.4倍。将所有核心用于RegEx匹配并非总是可行或理想的选择——在这种情况下，DPU硬件加速器轻松领先于单线程SIMD实现，并能显著节省CPU资源。

通过该实验能得出以下关于DPU硬件加速器的发现。

硬件加速器并非始终优于CPU。即便它们表现更优，也只能提升吞吐量，而非延迟。

将计算密集型任务卸载到硬件加速器可以节省大量CPU周期。

3.内存

用于对DPU的内存任务进行内存性能基准测试的参数如下表所示。

首先使用一个线程对上述所有内存大小执行随机和顺序读写操作。

图7展示了指针大小内存访问的吞吐量。

当对小至16 KB的对象进行随机读取时，该对象可在所有平台的L2缓存中缓存，因此访问效率很高。如图7a所示，所有DPU和主机均可实现超过1亿次操作/秒的随机访问吞吐量。

在DPU中，BF-3的吞吐量最高，比BF-2高1.6倍，这一差距甚至大于主机与BF-3之间的差距（1.3倍）。

当我们将对象大小增加到4 MB时，DPU的吞吐量急剧下降：OCTEON、BF-2和BF-3的吞吐量分别下降78%、87%和75%。在此大小下，DPU的工作集很可能会溢出到L3缓存。

由于主机拥有更大的L2缓存（48 MB），其吞吐量仍保持较高水平。

为消除CPU缓存效应，实验进一步测试了1 GB的缓冲区，这在很大程度上超出了CPU缓存。可以看到，各平台的吞吐量均下降到下一个级别：主机的吞吐量降至5800万次操作/秒（下降83%），其次是BF-3，达到2000万次操作/秒，然后是OCTEON和BF-2，均为670万次操作/秒。

该实验表明，对于随机读取，DPU擅长缓存小对象，性能可与主机媲美。而随着缓冲对象大小的增加，DPU与主机的性能差距也会扩大。

上述发现同样适用于随机写入场景（图7c）。当访问超过L3缓存大小的对象时，所有平台的吞吐量均出现下降。性能最优的DPU仍为BF-3，但随着内存缓冲区大小的增加，其与主机的性能差距逐渐扩大。值得注意的是，OCTEON在随机写入任务中的表现显著优于BF-2，当缓冲区大小达到1 GB时，其性能已接近BF-3。

在顺序访问中，CPU预取机制发挥着关键作用。如图7b和7d所示，内存对象的顺序读写性能正如预期的那样，远高于随机访问。通过实验结果可观察到以下几点：

首先，DPU的预取效率与主机相当——当对象大小在16 KB至1 GB范围内变化时，所有平台在读写操作中的吞吐量基本保持稳定。

其次，DPU与主机的性能差距相比随机访问场景更小，尤其是在中大型数据规模下，例如主机在顺序读取时比BF-2快5.9倍（而随机读取时这一差距为8.6倍）。

最后，DPU甚至能实现比主机更高的吞吐量：具体而言，当向1 GB内存执行顺序写入时，BF-3的吞吐量达到22亿次操作/秒，高于主机的15亿次操作/秒。

图8展示了CPU核心数量如何影响内存访问。

具体而言，多个线程并行随机访问16 KB的内存缓冲区。可以看到，单个线程无法充分利用内存带宽，且所实现的吞吐量随线程数量呈线性增长。

然而，DPU的核心数量较少（BF-2、BF-3和OCTEON分别为8、16和24个核心，而主机有96个核心），这限制了它们的最高内存访问性能：BF-2为13亿次操作/秒，OCTEON为27亿次操作/秒，BF-3为43亿次操作/秒。相比之下，主机使用32个核心即可实现113亿次操作/秒的吞吐量。

内存基准测试结果总结如下：

DPU 擅长顺序访问内存对象，有时甚至性能超过主机。

若为随机内存访问，DPU 更适合处理小对象，对大对象的访问能力较弱。

DPU 的核心数量有限，可能成为高吞吐量内存访问的瓶颈。

六、IO效率

接下来，将展现三款DPU 的 I/O 性能（包括存储 I/O 和网络 I/O）的评估结果，并以主机的 I/O 性能作为基准。

1.存储

存储基准测试的测试参数如下表所示。

与内存基准测试类似，实验评估了顺序和随机读写的性能。

实验改变了访问粒度、未完成请求的数量和并行度。由于存储I/O是异步的，因此实验同时测量了延迟和吞吐量。

首先在每个DPU和主机上调整上述参数，以实现最高的存储I/O吞吐量。结果如图9所示。

从所有测试设置中，观察到三个性能层级：OCTEON和BF-2上最慢的eMMC闪存设备（数十至数百MB/s）、BF-3上较快的NVMe固态硬盘（数百至数千MB/s），以及主机上性能最佳的NVMe固态硬盘（数千MB/s）。

尽管BF-3的NVMe固态硬盘比其他DPU的存储设备快得多，但与主机存储设备仍存在较大差距——速度慢2.8至10.5倍。

主机存储性能比性能较慢的DPU高出两个数量级。存储测试参数的影响因平台而异。

在执行随机读取时，将访问大小从8 KB增加到4 MB会降低随机性程度（因为一次访问内的字节会从设备中顺序读取），这对BF-2和BF-3的益处大于OCTEON和主机（吞吐量分别提升350%和440%，而后者仅提升50%和150%）。

当将访问模式从完全随机读取改为顺序读取时，BF-2在小尺寸访问下的吞吐量显著提升：在8 KB读取时提升了250%。这种优势在其他平台中并未体现：主机仅观察到17%的差异，这表明SSD在随机访问中的效率。

总体而言，写入速度通常慢于读取速度（图9c和9d对比图9a和9b）。与读取类似，OCTEON和BF-2在写入性能上慢于BF-3和主机，且不同的访问大小和模式对BF-2的影响最大。BF-3与主机在写入场景下的性能差距比读取场景更大。

图10展示了存储I/O延迟。

该实验将未完成请求数和线程数均设为1，以实现各平台的最低延迟。图10a和10b分别报告了8 KB和4 MB访问的平均延迟和尾部延迟。

可观察到比吞吐量结果更有价值的现象：DPU（尤其是BF-3）的延迟可与主机相当，甚至更低。对于小规模随机和顺序读取（图10a），BF-3的尾部延迟比主机低约20%，其在处理随机读取时的平均延迟也更低。

考虑到DPU存储设备到网络接口的距离更短，这在处理远程存储请求时具有特别优势。然而，当访问更大块（4 MB）且性能受带宽限制时，图10b显示即使在BF-3上，耗时也比主机高3-5倍。

尽管DPU上的直连存储设备属于辅助性质，并非针对路径上的应用卸载，但我们仍发现了存储卸载可发挥作用的场景。

以下总结了从存储基准测试中得出的发现：

DPU通常在吞吐量受限的大型I/O场景中提供比主机低得多的存储性能。

最新的DPU在细粒度访问时可实现低延迟。

2.网络

最后一项微基准测试聚焦于网络数据传输性能。实验搭建了一个物理网络，其中远程服务器（配置与主机相同）通过100 Gbps线缆连接至其中一个DPU（BF-2）。

测试参数如下所示。

实验同时测量了网络传输延迟和吞吐量。

首先探究网络延迟。

测量方法：在远程服务器上启动一个线程，该线程发送闭环乒乓消息以精确测量网络往返延迟。

实验将远程服务器与DPU之间的延迟，与远程服务器和本地主机之间的延迟进行了对比。这一比较旨在评估DPU用于通信卸载的效率。

图11a展示了不同消息大小下的平均延迟和尾部延迟。可观察到，总体上，在所有消息大小下，远程服务器（简称“remote”）与DPU之间的延迟均高于远程服务器与主机之间的延迟。平均来看，前者比后者高30%。

DPU上的这种延迟开销可归因于其较弱的CPU——Linux TCP/IP协议栈运行于此，导致软件处理速度变慢。

接下来测量网络吞吐量，上述现象在此也得到了体现。

测量方法：让远程服务器与DPU/主机创建多个线程，每个线程处理一个连接以交换大消息（32 KB）。每个连接维持128的队列深度，以确保连接吞吐量达到饱和。

图11b显示了远程与DPU之间以及远程与主机之间的网络吞吐量。

趋势很明显——与主机的性能差距比延迟测试中更大。

单线程情况下，DPU可实现8 Gbps的吞吐量，而主机的单线程吞吐量高达38 Gbps，是其4.8倍。DPU和主机均在四个线程时达到峰值吞吐量，此时DPU的吞吐量为22 Gbps，主机为98 Gbps。事实上，主机的单线程吞吐量比DPU八核的吞吐量还高1.7倍。

该结果表明，利用板载Linux中的TCP/IP协议栈将高吞吐量网络通信卸载到DPU会导致显著的性能下降。

为验证上述效率低下源于在较弱核心上运行的软件栈，研究人员在dpBento中实现了一个额外的插件任务，用于借助BF-2 DPU支持的InfiniBand远程直接内存访问（RDMA）进行网络基准测试。RDMA绕过板载Linux，直接访问网络接口控制器（NIC）以进行数据传输。具体而言，该任务使用NVIDIA提供的ib_read_lat和ib_read_bw工具，执行从远程服务器到DPU/主机的RDMA读取，并测量网络性能。

实验使用与之前延迟和吞吐量测量相同的参数来评估性能。

图12a和12b对比了远程服务器与DPU之间、以及远程服务器与主机之间绕过内核的延迟和吞吐量。可观察到，当绕过板载操作系统中的网络栈时，与DPU的网络通信延迟低于与主机的通信延迟。

如图12a所示，在访问4 KB数据时，DPU的延迟比主机低12.6%。

这一更低的延迟可以解释为：从网络接口控制器（NIC）到DPU内存的距离比到主机内存的距离更短。

在吞吐量方面，尽管DPU的单连接性能仍低于主机，但差距已非常小（11.3%）。DPU和主机均在使用两个线程/连接时达到峰值吞吐量，此时两者的吞吐量差距进一步缩小。

下面总结关于DPU网络的见解。

将网络通信通过DPU板载TCP协议栈进行卸载会降低性能，尤其是吞吐量。

绕过内核的网络技术可消除弱核心的影响，甚至实现比主机更低的延迟。

七、DPU卸载的优势

接下来探究DPU所支持的近数据处理和增强处理能力的优势，并展示将dpBento中包含的两个云数据库模块卸载到不同DPU上的结果。

1.谓词下推

将数据库规模固定为10 GB（TPC-H规模因子10），谓词选择性固定为1%，并将DPU上用于扫描的核心数量从1个变更为所有可用核心。

图13展示了基本扫描和支持DPU谓词下推的性能。

将整个表从存储服务器获取到计算服务器的基准场景会产生高昂的网络和存储I/O开销，因此扫描吞吐量较低——每秒3300万元组（MTPS）。

将谓词下推到存储服务器上的DPU可以消除大部分数据移动：较弱的DPU（即BF-2和OCTEON）在使用两个核心进行扫描时性能超过基准场景，当使用其所有DPU核心时，吞吐量达到150 MTPS，比基准场景快4.5倍。BF-3的速度明显快于其他解决方案。其单核心性能较基准场景提升1.8倍，使用全部16个核心时提升12倍。该结果证实了DPU在近存储数据处理方面的潜力。

2.索引卸载

为评估将DPU用作主机协处理器时的性能提升，实验构建了一个50GB的索引（包含5000万条1KB记录），并按10:1的比例在主机与DPU之间拆分。随后，分别在主机和DPU上执行均匀读取操作，并测量整体索引吞吐量。

近期研究已报道了通过在主机与BF-1、BF-2 DPU之间分担索引工作负载实现的性能提升，本文研究人员的实验进一步在更新一代的DPU（BF-3）和另一品牌DPU（OCTEON）上验证了这一优势。

结果如图14所示：在未进行任何卸载时，主机通过96个线程可实现920万次操作/秒（MOPS）的吞吐量；通过将部分索引卸载至DPU，单位时间内可处理更多请求。尽管单个DPU核心性能弱于主机CPU，但充分利用DPU仍能带来显著性能提升——卸载至OCTEON、BF-2和BF-3时，吞吐量分别提高19%、10.5%和26%。

八、端到端数据库管理系统性能

最后，将使用dpBento的内置DBMS任务对DPU进行基准测试。

需要明确的是，实验的目标并非倡导在DPU上部署完整的系统。相反，研究结果认识到这样做的开销，从而推动数据系统和DPU之间的协同设计，这与近期纳入部分卸载方案的提议一致。

在每个DPU平台上，将所有可用核心分配给DuckDB，并测量其在冷执行和热执行状态下处理每个TPC-H查询（规模因子10）的运行时间。

图15a展示了冷执行的结果。

正如预期，主机性能优于所有DPU。其平均查询执行性能分别比OCTEON、BF-2和BF-3高87倍、43倍和2.1倍。这种执行模式的主要瓶颈是磁盘I/O，尤其是在扫描表并将其加载到主内存时的顺序读取。

回顾第六节第1小节，OCTEON和BF-2上的eMMC闪存比BF-3和主机上的NVMe SSD慢得多，这反映在端到端的查询执行中。

在DPU之间，BF-3比其前一代快21倍，如图9b所示，BF-2实现了更高的顺序读取性能，因此BF-2上的平均查询处理时间比OCTEON短2倍。

在热执行中观察到不同的现象，如图15b所示。由于避免了磁盘I/O，CPU和内存性能现在成为查询执行的主导因素。与冷执行相比，主机与性能最佳的DPU（即BF-3）之间的差距（3倍）有所扩大。这可归因于CPU和内存的差异。DPU的核心数量少得多（BF-3为16核，而主机为96核）。这也解释了OCTEON（24核）和BF-2（8核）之间的变化：前者在冷执行中速度较慢，现在却快了2.7倍。

总之，在运行完整的数据库管理系统（DBMS）时，存储性能、CPU性能、核心数量以及内存效率共同导致了主机与DPU之间的显著性能差距。

九、相关工作

1.DPUBench提出了一个针对DPU的基准测试套件。

该基准测试套件包含用于存储、网络和安全的操作算子，还包括使用这些操作算子进行通信、文件压缩与完整性检查以及安全处理的端到端应用程序。

然而，DPUBench仅评估了BF-2。

尽管DPUBench与dpBento共享一些操作算子基准测试，但它不足以评估数据处理系统——而这正是dpBento的主要贡献。

2.DPU-Bench评估了高性能计算（HPC）场景下的DPU性能。

具体而言，该基准测试套件测量了基于远程直接内存访问（RDMA）的、与BF-2的消息传递接口（MPI）通信性能，旨在确定能最大化卸载效率的DPU进程数量。

后续工作对BF-2和BF-3进行了对比。相比之下，dpBento专注于DPU卸载数据处理任务的能力。

3.Wei等人对BF-2上各种远程直接内存访问（RDMA）路径的性能进行了量化分析。

基于基准测试研究，该工作提出了优化指南，并将其应用于先前的DPU加速文件系统和KV存储。

4.Chen等人对BF-3进行了更全面的性能研究（涵盖计算和通信），重点关注RISC-V数据路径加速器（DPA）。