【论文阅读】DPDPU：基于DPU的数据处理

霞姐聊IT

发布于 2025-05-30 08:24:55

3500

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

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

一句话总结：

这篇文章聚焦云数据系统中性能与成本优化难题，指出数据处理单元（DPU）作为可编程 NIC 的新一代硬件平台，虽具潜力但面临抽象不匹配、资源多样及硬件异构等挑战。

因此文章提出DPDPU 框架，通过计算、网络和存储三大引擎，旨在弥合 DPU 与数据处理系统的语义鸿沟，实现跨硬件资源的高效任务调度与硬件无关的编程接口。

同时文中对DPDPU的计算、网络和存储三大引擎的设计进行了进一步阐述、并介绍了DPDPU的当前进展及未来计划。

一、研究背景和挑战

1.云数据系统的性能与成本困境

(1)通用处理器的速度提升跟不上数据增长的步伐，导致在处理大规模数据时，计算密集型任务的性能逐渐下降。

(2)高速带宽的I/O 设备（如SSD和NIC）极大地提高了数据传输速度的同时也消耗了更多 CPU 资源。

(3)计算与数据的分离加剧了网络通信负担

2.现有解决这些挑战的方案有其局限性：

方案一：使用领域专用硬件进行硬件加速（例如GPU和 FPGA）

局限性：需要深厚的硬件专业知识，并将领域特定的非可移植性特征嵌入到系统设计中

方案二：采用用户空间I/O 绕过操作系统内核（例如 RDMA 和 SPDK）

局限性：需要修改应用程序，但现有大规模软件系统（如数据库管理系统）难以采用此方案

方案三：利用缓存和计算下推来最小化数存分离的影响。

局限性：此方案在提升性能方面有效，但在降低成本方面却力有不逮。

3.数据处理单元（DPU）方案

DPU作为最新一代的智能网卡，正成为一个颇具前景的硬件平台。

DPU 是一种片上系统（SoC），配备了一系列针对数据路径效率优化的硬件资源。

其中包括高能效的CPU（如 Arm 内核）、硬件加速器（例如压缩/解压缩和加/解密ASIC）、网络处理器以及适量的板载内存。

DPU 旨在克服现有方案的局限性。作为片上系统（SoC），DPU 可独立于主机运行。因此，它无需修改主机应用程序即可增强整体系统架构，提升了可移植性和采用率。

此外，DPU 能够以线速卸载主机的 I/O 处理任务，降低主机的资源消耗。

4.想有效利用DPU有三大挑战

(1)挑战一：抽象不匹配。

DPU 是面向数据包的网络设备，其暴露的编程接口并不适合数据系统开发人员和运维人员。

例如，英伟达的DOCA和英特尔IPDK允许用户构建网络内卸载流水线。

它们提供了DPDK、OVS和 P4等库，使用户程序能够操作数据包、流和原始字节，而非数据对象（如pages和records）。因此，数据系统需要更友好的 DPU 接口和工具包。

(2)挑战二：资源多样性。

DPU SoC包含一系列硬件资源，从通用 CPU 核心到用于硬件加速的专用 ASIC 不等。

为各种数据处理任务编排这些处理单元，并根据工作负载动态在它们之间调度任务，并非易事。

静态分区方案（例如让 ASIC 执行受支持的工作负载，而 CPU 处理剩余任务）可能导致资源利用率低下和负载不均衡。

先前的研究表明，仅在 DPU 上进行核心调度就面临诸多挑战。若再纳入板载内存、高速网络接口以及对 PCIe 对等设备的直接访问（即不经过CPU直接访问SSD、FPGA）等其他资源，只会进一步增加资源分配和调度的复杂性。

(3)挑战三：DPU 异构性。

硬件厂商和云服务提供商正在生产各自的DPU，例如 NVIDIA BlueField 、Intel IPU 、Microsoft Fungible、阿里巴巴 CIPU 和 AWS Nitro。

要在不同数据中心的异构DPU 上运行数据系统，需要一个支持可移植性的基础设施。

这些DPU 在高层架构特征上有相似之处，但在详细的硬件规格上存在显著差异。

例如，NVIDIA BlueField-2 配备了正则表达式硬件加速器，而 Intel IPU 甚至 NVIDIA 自己的 BlueField-3 都没有该加速器；

BlueField-3 支持将通用代码卸载到 NIC 核心，而大多数其他 DPU 仅支持匹配 - 动作表风格的网络卸载。

更糟糕的是，DPU 厂商通常会提供自己专有的板级编程 SDK。

如果没有一个可移植的框架，开发人员在切换到不同硬件时必须手动重写所有DPU 特定的优化。

文章提出了DPDPU，这是一个以 DPU 为中心的云数据处理整体框架。文章的核心见解是，当上述障碍得到解决时，数据系统可以高效利用 DPU 来优化广泛的任务，例如计算密集型、网络密集型或存储密集型工作负载。

DPDPU包含三个组件，以合理利用各种DPU资源：

(1)计算引擎：运行在DPU CPU核心和硬件加速器上，用于处理计算任务，如开销较大的路径数据操作（如压缩和加密）和下推数据库操作符（如谓词和聚合）；

(2)网络引擎：将通信原语从主机CPU卸载到DPU网络接口；

(3)存储引擎：利用对存储设备的直接访问来提高本地和分拆式存储的性能，同时节省成本。

DPDPU还会根据任务规格和资源可用性，在DPU硬件加速器、DPU CPU和主机CPU之间调度任务。

DPDPU 提供了高层次、硬件中立的接口，以减轻DPU 加速数据系统的编程和移植工作。用户通过编写存储过程来在计算引擎中表达任务。

网络引擎和存储引擎公开了常见的异步I/O 抽象，使现有数据系统能够以最小的工作量采用DPDPU。

在框架中避免使用特定厂商的功能，从而确保基于DPDPU 的自定义优化可以在不同 DPU 之间移植。

为处理硬件异构性，文章提出了DP 内核抽象，用于统一硬件加速器和 CPU。

当某个DP 内核不被任何加速器支持时，DPDPU 会在 DPU CPU 或主机 CPU 上执行该内核，并将决策通知给应用程序。

这篇文章贡献如下：

(1)文章展示了云数据处理中性能和成本方面的挑战，并阐述了 DPU 带来的机遇。

(2)文章介绍了DPDPU的整体愿景。

(3)文章讨论了DPDPU每个组件面临的挑战，并提出了高层设计。

(4)文章调研了相关的前期工作，报告了当前的进展，并提出了DPDPU的下一步计划。

二、云计算中的新挑战

本节将阐述在云端运行数据系统时面临的性能和成本效率挑战。

文章通过micro-benchmark提供量化证据，包括计算密集型和 I/O 密集型任务的效率，以及资源（存储）分拆带来的开销。

1.计算效率低下

在过去十年中，CPU 的性能提升已逐渐放缓。另一方面，数据系统却频繁调用计算密集型子程序。例如，DBMS通常会在网络传输前对数据进行压缩和加密，以减少网络流量并保障数据隐私与安全性。那么，数据系统是否仍能依赖 CPU 来维持这些计算任务的良好性能呢？

为了回答这个问题，作者们在AMD EPYC CPU和Arm CPU上对不同规模的自然语言数据集进行了数据压缩（使用无损DEFLATE算法）的性能测试。结果如下图所示，尽管更先进的EPYC CPU性能优于Arm CPU，但在压缩更多数据时，两者都面临着高延迟且延迟不断增加的问题。这一结果表明，当数据系统管理大规模数据时，执行计算密集型操作是难以处理的。

2.I/O成本

文章衡量了执行数据库系统中最常见的任务之一：高带宽I/O的CPU成本，具体来说，是评估了从Linux管理的SSD访问8KB页面的CPU消耗。

如下图所示，CPU周期数随着I/O吞吐量的增加呈线性增长。当吞吐量达到每秒45万个页面时，平均CPU消耗高达2.7个核心。

文章还使用较新的io_uring测试了Linux存储性能，但观察到了相似的CPU成本。

此处的实验表明，具有高I/O需求的数据系统将消耗大量CPU资源，这意味着更高的硬件成本。

3.分拆开销

文章评估了资源分拆的开销。

在存储分拆场景中，计算和存储部署在通过网络连接的不同服务器上，这在当今的云数据中心已十分常见。

这种架构为资源管理提供了更高的灵活性，但代价是存储访问需要额外的网络 I/O，从而导致更高的访问延迟甚至更多的 CPU 消耗。

为了量化分拆带来的延迟和 CPU 消耗开销，文章测量了通过 TCP/IP 套接字在100 Gbps 网络上传输 8 KB页面的网络通信成本。

如下图所示，分拆引发的额外网络 I/O 会消耗大量 CPU 资源，尤其是在更高带宽的情况下。并且此类 I/O 处理会与其他计算任务竞争 CPU 资源。

三、DPU带来的机遇

DPU 是基于片上系统（SoC）的智能网卡。

下图展示了英伟达BlueField-2（BF-2）的架构，这是一款已大规模量产的主流DPU‘’。

DPU上的资源可分为五类：（1）高能效CPU核心，（2）板载内存，（3）硬件加速器，（4）高速网络接口，以及（5）PCIe接口。

具体而言，BF-2包含8个主频为2.5 GHz的Arm A72核心、16 GB DDR4内存、一组硬件加速器（包括正则表达式、压缩、加密和去重功能）、带宽为100 Gbps的ConnectX-6网卡，以及一个可访问主机内存和其他PCIe连接设备（如SSD和GPU）的PCIe 4.0交换机。

尽管不同厂商的硬件配置细节有所不同，但这一特征可推广至其他DPU，例如英特尔IPU和微软Fungible。这些资源与DPU数据路径优化相结合，可用于应对上述挑战。

为提升计算效率，数据系统可利用硬件加速器在数据路径上执行计算密集型操作。这些加速器是为特定计算任务设计的ASIC；与通用处理器相比，专业化设计可提高能效和性能。

下图显示，BF-2上的压缩加速器性能比CPU高出一个数量级。

为降低I/O成本，DPU通常提供高级用户空间库以构建高效的I/O流水线。例如，BF-2采用SPDK和DPDK，使用户能够在用户空间直接访问存储设备和网络接口，而无需主机参与。结合DPU上的通用CPU核心和适量内存，用户可构建任意低延迟、高带宽的I/O服务，使主机摆脱高开销的存储和网络I/O操作。

尽管DPU具有潜在优势，但为了更好地将其应用于数据处理系统，仍需解决抽象不匹配、资源多样性和DPU异构性等方面的挑战。

四、DPDPU框架

文章设想了一个由DPU驱动的软件平台，该平台利用上一节提到的机遇来解决云数据处理问题。文章将这个平台称为DPDPU，它通过以下方式实现这一目标：

（1）弥合原始DPU资源与云数据处理任务之间的语义鸿沟；

（2）高效利用单个DPU上的多样化硬件资源；

（3）将不同DPU的详细硬件配置与数据系统层的优化解耦。

如下图所示，DPDPU包含三个模块：计算引擎、存储引擎、网络引擎，可针对计算密集型和I/O密集型操作进行优化。

DPDPU组件与访问的资源：

下文简要描述每个组件所管理的DPU资源以及组件之间的交互。后续章节将讨论每个组件的详细设计和关键挑战。

计算引擎为数据处理任务提供高效且通用的计算能力。

该引擎精心协调跨四种计算资源的计算密集型任务：DPU板载CPU、DPU硬件加速器、主机CPU，以及通过PCIe连接的其他主流数据中心加速器（如GPU和FPGA）。执行的工作集可缓存在DPU内存和主机内存中。

网络引擎负责处理网络I/O。

它利用DPU内置的先进网络功能（高速接口、匹配动作卸载和用户库）来提升网络I/O效率。具体来说，DPU的DMA引擎充当抽象边界，将主机应用使用的主流网络方法的前端与协议执行解耦——协议执行通过板载内存、CPU和网络接口卸载至DPU。

存储引擎可提升存储路径效率，涵盖来自本地应用和远程客户端的请求。

对于本地应用，该引擎提供轻量级用户库，用于将存储请求从客户端转发至DPU，DPU通过PCIe P2P通信访问SSD。对于远程客户端的请求，存储引擎会与网络引擎协同工作，直接在DPU上执行存储请求，无需主机参与。

不同的DPDPU组件可组合起来执行数据系统中的复杂任务。

例如，针对一个带有压缩数据的远程存储访问请求，DPDPU程序可能会先使用存储引擎从本地SSD读取数据，然后调用计算引擎以利用DPU的压缩加速器对数据进行压缩，最后由网络引擎将结果交付给客户端。

再以谓词下推为例：利用DPDPU，存储服务器首先通过存储引擎从固态硬盘（SSD）读取数据库记录，然后直接使用计算引擎对这些元组应用谓词过滤，最后仅通过网络引擎将符合条件的元组返回给远程数据库服务器。

DPDPU通过两种机制促进组件的可组合性。

首先，它借助DPU内存实现三个引擎之间的状态共享。状态模式和缓存数据可由应用程序自定义。不过，在每个组件内部，由于异步访问（如通过PCIe对网络、硬件加速器和主机资源的访问），无法保证一致性。

此外，DPDPU支持跨引擎边界的高效、流线型数据通信。为此，各引擎的API和执行模型支持流水线式数据处理——一个引擎的输出可直接流式传输至另一个引擎，而无需等待当前任务完成。从而可以构建高效的异步流水线，实现I/O与计算的重叠处理。

五、计算

1.计算引擎（CE）的设计目标：

（1）高效。计算引擎（CE）的主要设计动机是解决计算效率低下的问题，因此需最大限度地提高卸载至CE的计算任务的执行效率。

（2）通用。为了惠及各类云数据处理系统，计算引擎（CE）应能处理广泛的任务，从数据路径原语（如压缩和加密）到关系运算符下推。

（3）易编程。DPU 编程的一大难点在于不同处理单元之间的底层接口。计算引擎（CE）提供数据系统开发人员熟悉的 API，以提高易用性。

（4）可移植。除了要在不同DPU 之间具备可移植性之外，CE 在执行相同的用户任务时，还必须能够兼容 DPU 和主机上的各种异构计算资源。

2.接口：

DPDPU为用户提供存储过程（sprocs）来表达其计算任务。

先前的研究已探索将存储过程用作通用编程抽象，以卸载数据处理系统的计算任务。尽管存储过程具有诸多优势，但其主要是为CPU 执行而设计的；该抽象缺乏对硬件加速的原生支持。

为克服这一限制，DPDPU引入 DP 内核（DP kernels），DP内核是DPDPU 中内置的一组可扩展专用函数，用于优化存储过程（sproc）的执行效率。

用户可以查询计算引擎（CE）中可用的 DP 内核，并选择符合应用需求的内核。

但DP 内核不会向开发者暴露硬件级别的细节。

结合DP 内核的存储过程自然满足了计算引擎的通用性和易编程目标。下文将继续讨论执行细节，并解释计算引擎如何实现效率与可移植性。

3.执行过程

存储过程（sproc）首先在计算引擎（CE）中注册，CE会将其预编译为共享库。在运行时，该库被加载到用户程序中，并在DPU的CPU核心上运行。

DP内核（DP kernels）代表计算密集型任务，因此会优先进行硬件加速以最大化计算效率。然而，由于硬件的异构性，某些硬件加速器并非在所有DPU目标平台上都通用。例如，BlueField-2包含一个正则表达式（RegEx）引擎，而BlueField-3和英特尔IPU上则没有该引擎。

为确保相同的用户代码能在不同DPU上运行，DP内核必须具备可移植性以及向前/向后兼容性。所以需要每个DP内核均可在任意计算硬件（如CPU、ASIC、FPGA或GPU）上执行。

运行时的实际执行完全取决于硬件的可用性。

允许用户指定DP内核的执行位置（指定执行）；计算引擎（CE）也可针对所有DP内核构建调度（调度执行）。

调度执行使CE能够在目标平台的硬件约束下，优化存储过程（sproc）的整体性能。

4.示例

下图展示了一个包含 DP 内核的存储过程（sproc）示例。

该存储过程处理来自远程客户端的请求，需读取一组页面、对其进行压缩，并将压缩后的页面返回给客户端。

由于压缩是此存储过程中计算量最大的任务，所以使用压缩内核（dpk_compress）对其进行加速。

在此示例中，用户首先指定在内核压缩加速器上执行（第 20 行）。如果 DPU 当前无法使用该加速器，用户会将计算任务转移到 DPU 的 CPU 核心上（第 24 行）。

或者，在实现时可以不在 dpk_compress 中指定目标设备。此时，内核将由计算引擎（CE）进行调度，并且该调用始终会返回一个进行中的有效工作项。

指定执行的主要优势在于程序行为具有可预测性；然而，这也将优化存储过程（sproc）性能的负担留给了用户。

5.开放性挑战。

开发计算引擎（CE）必须应对若干技术挑战。

首先，存储过程（sproc）可能在高并发场景下被频繁调用（例如接收到数据包时），因此合理的调度机制对整体性能至关重要。

此前的研究采用多种调度策略来实现高性能的网络接口卡（NIC）卸载能力。例如，iPipe 通过先到先服务（FCFS）队列和差分轮询（Deficit Round Robin DRR）队列，分别在DPU CPU核心与主机CPU核心上调度低方差和高方差任务。

CE不仅需要在DPU和主机CPU之间调度存储过程，还需在所有计算单元上调度DP内核。硬件加速器具有厂商特定的特性（如高吞吐量但高延迟），与CPU的特性截然不同。

这使得DPDPU的调度问题空间被扩展为：如何在同一加速器上调度DP内核？如何协同调度存储过程与DP内核？如何满足不同应用的性能目标？

其次，配备 DPU 的服务器可运行多个应用程序。在多租户环境中，提供公平性和性能隔离至关重要。

一种简单的方法是使用容器对 DPU 和主机上的 CPU 及内存进行资源切片。然而，完整的解决方案还必须考虑硬件加速器。

与 CPU 相比，不同硬件的加速器容量（即并发任务数）差异很大，且这些加速器缺乏虚拟化支持。因此，在加速器上实现资源复用和 DP 内核执行的隔离是一项挑战。

最后，当通过 PCIe 连接额外的通用数据中心加速器（如 FPGA 和 GPU）时，DPDPU 的计算引擎（CE）可进一步扩展。

首先需要将 DP 内核映射到这些设备上，并基于存储过程（sproc）及其DP 内核在不同位置的分布情况，制定高效的数据迁移方案。

由于这类加速器比 DPU 内置的硬件加速器具有更高的资源容量（更多核心和内存），因此将多个 DP 内核在加速器内部融合以最小化执行延迟是合理的。此外，需要扩展此前针对相关挑战的解决方案，以纳入更多 PCIe 设备。

六、网络

1.设计目标

网络引擎（NE）的主要设计目标是降低通信开销，同时为流行的传输协议（如 TCP，以及近年来的 RDMA）保持高性能。

NE 的设计原则是将消耗 CPU 资源的网络活动卸载到 DPU 上，仅保留模拟现有通信框架 API 的轻量级前端库。这得益于 DPU 的 DMA（直接内存访问）和数据包生成能力。

2.TCP 优化

传统的TCP/IP 协议栈仍是数据处理系统中最常用的网络通信协议。高 TCP 吞吐量会消耗大量主机 CPU 周期。

有的方案试图通过将TCP 协议栈的部分功能卸载到 DPU 上来提升 TCP 的 CPU 效率。例如，IO-TCP 将 TCP 分为控制平面（连接管理、拥塞控制等）和数据平面（数据传输）；其在单个主机 CPU 核心上运行控制平面，在 DPU 上运行数据平面。

然而，这些解决方案针对特定应用（如用于流媒体文件的IO-TCP），且需要修改应用程序。

为支持分布式和分拆式数据处理的通用通信，本文建议将TCP/IP协议栈迁移至DPU，并通过用户库为宿主应用提供类POSIX套接字API。

此举需要应对两大挑战：

挑战一，由于DPU上的CPU性能显著弱于主机CPU，必须对DPU上的TCP/IP协议栈进行精细优化，避免性能下降；

挑战二，由于网络消息最终在主机端处理，流控机制现在需要跨主机和DPU协同工作。

因此必须协同设计DPU上的TCP协议与主机-DPU通信机制，以便在流控协议中反映来自主机应用的信号。

3.RDMA优化。

RDMA是一种很有前景的数据中心网络技术，可在数据处理系统中实现高速网络通信。RDMA在用户空间运行，能完全绕过操作系统开销，还可通过网卡硬件的DMA避免远程CPU的参与。

为了在数据库系统中充分利用RDMA，DFI在传输层之上构建了数据流接口，以提供流水线式、以线程为中心的流执行。它实现了接近原生RDMA网络的通信性能。

尽管与传统网络栈相比，RDMA在性能上有优势，但发起RDMA操作仍会消耗大量CPU资源。例如，访问RDMA队列对中的发送/接收队列时，需要使用自旋锁和内存屏障来确保队列顺序。当向RDMA网卡的门铃寄存器发送信号时，还可能导致CPU停滞。这些开销已被近期的研究证实。

下图展示了DPDPU的优化RDMA通信的方案。

设计将繁重的发送端RDMA处理卸载到DPU上。

首先用无锁环形缓冲区替换RDMA队列，以接收用户请求。这些缓冲区支持DMA访问，因此DPU上的网络引擎（NE）可利用DPU的DMA引擎轮询用户请求。

接收到请求后，NE会发起相应的RDMA读/写或发送/接收操作，以访问远程机器上的内存。这种RDMA异步执行必须与主机上的非阻塞接口协同工作，从而使应用程序仅需消耗最少资源来轮询响应。

Cowbird为分拆式内存提出了一种异步I/O抽象；它将RDMA卸载到可编程交换机和回收的虚拟机上。DPDPU的网络引擎（NE）可视为Cowbird的扩展，其目标是支持通用网络通信，同时支持单边和双边RDMA。关键挑战在于协同设计接口和整套RDMA操作的执行，以最大限度降低主机和DPU上的资源消耗。

可以应用网络引擎（NE）来优化DFI。

具体而言，DFI的接口与其RDMA执行可实现解耦，使得运行在主机上的数据系统仍能通过流接口将记录发送至远程机器。这些请求会被缓存在主机内存中，随后转移至DPU以进行进一步的数据流处理。为此，需要将DFI的RDMA可访问缓冲区重新设计为包含主机管理的DMA缓冲区和DPU管理的RDMA缓冲区。

七、存储

DPDPU 中的存储引擎（SE）的设计源于 DPU 在存储领域的两大优势：

首先，将文件相关操作卸载到DPU 上可以释放大量主机资源；

其次，DPU 位于数据通路上，能够为分拆式存储的请求提供服务。

鉴于存储I/O 会消耗大量 CPU 资源，第一个优势显而易见。下图展示了第二个优势：当远程存储请求到达 DPU 时，SE 可以通过访问 PCIe 连接的 SSD 立即处理该请求。

相比之下，现有的分拆式存储必须使用主机CPU 处理请求，这会产生额外的 PCIe、操作系统和存储栈开销。

1.文件执行卸载。

本文设计了一个基于DPU 的存储框架，可为主机应用提供类 POSIX 文件系统 API，以管理文件并执行文件 I/O 操作。

文件请求的处理被卸载至DPU。在DPU 上构建文件服务，利用用户空间存储解决方案（如存储性能开发工具包 SPDK）来优化文件 I/O 效率。

与网络引擎（NE）类似，通过用户库中的无锁环形缓冲区，可最大限度减少应用线程在发起文件请求和轮询响应时的竞争，且 DPU 会以延迟方式通过 DMA 传输请求。

设计要求将固态硬盘（SSD）的管理从主机服务器委托给DPU，这是采用DPU的一个流行趋势。

2.远程请求卸载

本文在存储引擎（SE）中设计了一个卸载引擎，允许用户直接在DPU上处理远程存储请求，从而充分利用DPU实现分拆式存储。

具体而言，用户提供一个用户定义函数（UDF），用于解析网络消息以识别可卸载的远程存储请求，并将其转换为文件操作。

一个简单的UDF可以从请求中提取文件ID、偏移量、大小和I/O类型（读或写），并构造相应的文件操作。

由于DPU已在上述DPU文件服务中维护了用户文件与SSD上物理块之间的映射（即文件映射），因此SE可以直接执行文件操作而无需与主机通信。

实现该设计的关键挑战在于DPU上的资源有限。

例如，在云原生数据库管理系统（DBMS）架构中，事务更新通过日志重放反映在分拆式存储服务器上。运行日志协议可能需要消耗高达数百GB的内存来缓存热页，以防止写放大。这一内存占用比DPU的内存容量（如16GB）大一个数量级。

因此，某些不适合DPU卸载的存储请求仍必须转发给主机。

这种部分卸载引发了几个技术问题：哪些请求应该被卸载？卸载API应如何设计以反映这种划分？如何在不违反传输协议语义的情况下拆分网络流量？

八、相关工作

智能网卡（SmartNIC）和数据处理单元（DPU）已在分布式系统和计算机网络领域得到探索。下面总结下该领域的几项最新研究成果。

LineFS 通过将 CPU 密集型任务卸载到 DPU 并利用流水线并行来提升性能，从而提高了分布式文件系统的效率。

iPipe提出了一个基于参与者的执行框架，将 DPU 用于分布式应用，支持在 DPU 和主机之间进行调度和灵活的负载迁移。

最近，IO-TCP提出了一种主机 - DPU 协同设计的 TCP 协议，该协议利用 DPU 的数据路径效率来卸载媒体文件的流式传输任务。

Lovelock是一个基于DPU的集群管理器，它消除了对主机服务器的需求（例如在硬件加速器和存储设备等方面）。

DPU在数据库领域正日益受到关注。

Thostrup 等人针对两个特定的数据库管理系统（DBMS）组件（B树索引和定序器），评估了特定DPU（NVIDIA BlueField - 2）的性能优势，其结果与我们对DPU的特性描述相符。

SmartShuffle则将数据Shuffle过程中的底层网络组件以及DBMS级任务卸载到DPU上执行。

DPDPU与其他研究的不同之处在于DPDPU提议的通用性。它系统地利用DPU片上系统（SoC）的能力来应对云数据处理中的一系列挑战。DPDPU中的三个互补引擎为数据系统优化提供了易于使用且可移植的DPU资源解决方案。

九、进展与下一步计划

实现DPDPU愿景的第一步是开发DDS。

DDS是一种DPU优化的分拆式存储服务器架构，是存储引擎的一部分。

回顾前文可知，DPU不适合完全卸载分拆式存储请求。

因此，DDS的设计围绕部分卸载展开，即远程存储请求由DPU和主机共同处理。

具体而言，DDS解决了三个关键问题。下文是关键问题以及解决方案。

（1）Q1：如何从DPU直接访问SSD上的文件？

解决方案：我们开发了一个统一文件系统，将主机上的文件操作导向DPU。这使DPU能够掌握文件映射关系，从而知晓如何处理远程请求。

（2）Q2：如何在DPU和主机之间引导流量？

解决方案：通过流量导向器解决，该导向器可确定每个数据包是应转发至DPU上的DDS还是主机上的端点，并且在完成此任务时不会破坏端到端的传输语义。

（3）Q3：如何实现通用且高效的DPU卸载？

解决方案：在卸载引擎中引入了高级API，供用户实现第七节所述的UDF（用户定义函数），并广泛采用零拷贝技术以最大化请求执行效率。我们将DDS与微软的两个生产系统FASTER（一个键值存储）和Azure SQL Hyperscale（一个云原生数据库管理系统）进行了集成。实证研究表明，DDS每个存储服务器最多可节省数十个CPU核心。