一种不带CPU的DPU架构：Hyperion

摘要：

引言

然而，即使在这个黄金时代，CPU仍然处于管理数据流[113]（数据复制、I/O缓冲器管理[100]）、加速器（例如PCIe枚举[120]）以及在OS级别（分组、请求、文件）与设备级别（地址、位置）之间进行转换的关键路径中[14、66、125、129]。表1展示了先前方法的概述。此外，在保持系统资源(dram、内存映射、 tlbs)的 cpu 和加速器视图一致和安全的情况下，总是完成加速器集成(通过虚拟化或多路复用)。尽管这种集成是必要的，但它给加速器管理带来了复杂性，并使CPU成为最终的资源仲裁器。与加速器和I/O设备相比，CPU性能预计不会大幅提高[101]，甚至会随着每次微架构攻击修复而下降[23，81]。我们不是第一个提出与CPU驱动的计算架构相关的问题的人[42，101]。尽管意识到了这一点，但CPU驱动的设计以及CPU仍然处于端到端系统构建的关键路径中，因此无法逃脱阿姆达尔定律[64]的影响。

第一原则推理提出了解决方案：没有CPU的系统，即零CPU或无CPU架构。像零cpu这样全新的计算架构将需要对计算硬件(总线、互连、控制器、DRAM、存储)、系统软件和应用程序进行彻底的、颠覆性的重新设计。此方法先前的一个示例是用于模拟的MSR BEE3系统[44]。最近的一个例子是ETH的Enzian系统，它设计了一个混合CPU-FPGA双插槽系统[41]。Enzian的论文记录了设计这样一个系统所付出的巨大工程努力，其中所有板组件都需要重新设计，以将FPGA作为协处理器与CPU集成。此外，这种以CPU为中心的思想鼓励我们继承和集成以CPU为中心的硬件和软件选择，以实现以加速器为中心的设计，而无需重新评估这些选择是否有意义和/或是否可以简化（参见§2）。

图1.Hyperion架构和布局

在这项工作中，我们采用了一种更实用的方法，并研究了称为Hyperion的统一NIC-FPGA存储数据处理单元（DPU）的设计（图1）。Hyperion的目标是在DPU内建立端到端的硬件控制/数据路径，而不涉及任何CPU。Hyperion的独特设计允许我们考虑构建一个独立的、自包含的DPU，其中不需要主机系统来运行它，从而降低了能源成本并增加了封装密度。这种直接连接网络的FPGA模型以前也曾使用过[69，111，123，133]。在本文中，我们介绍了这种独立DPU且没有CPU的情况（§2），并介绍了与硬件集成（§3.1）、系统软件（§3.2）以及客户端接口和工作负载（§3.3）相关的设计选择。

无CPU的DPU案例

首先，一个CPU的时代已经结束（设计、制造和热限制[34，51，63]），前进的方向是专业化与可重构的硬件和加速器。CPU的通用性具有开销（即，图灵税），这阻碍了性能或效率的专门化。例如，在DNA序列比对中，Smith Waterman算法的计算需要37个周期，40个指令(35个算法，15个加载/存储)，81纳焦耳的能量(在14nm的CPU上)。相比之下，在专用的40nm ASIC上进行计算需要一个单周期指令，其能量为3.1皮焦耳[131]。针对任何工作负载的CPU的通用性和过度工程设计也导致了较差的片上资源利用率[52]，未使用的硅[51,63]，以及更高的安全风险[81]。与此同时，随着开源EDA流程和项目的出现[7,8]，探索工作负载专用的硬件设计(带或不带CPU)变得更容易实现和负担得起。

其次，保持CPU驱动设计的直接后果是继承其内存寻址选择、转化以及保护机制，如虚拟内存、分页和分段[45]。当诸如FPGA之类的加速器作为外部设备[39]或协处理器[41]连接到CPU时，存在提供/移植熟悉的存储器抽象（如统一虚拟存储器[84]和/或共享存储器[94]）的诱惑。这种设计需要与其他CPU附加内存抽象（如页表和TLB、虚拟化、大型页面、IOMMU等）进行复杂集成，同时保持这种集成与系统的CPU视图一致[84，94]。此外，在具有加速器和异构CPU的现代计算平台上管理物理内存（或平面、统一物理地址空间的假象）是一项重要而复杂的工作[10]。因此，在这项工作中，我们认为避开CPU及其设计包袱，我们可以探索新的内存管理设计，例如编译器/语言辅助解决方案，甚至直接在物理地址上[126]。

最后，以CPU为中心的设计鼓励活动资源分解，其中资源仍然连接到管理分解逻辑的主机CPU。这种设计导致分解粒度更粗，软件复杂且臃肿[56]，处理器/内存紧密集成[61，122]。以实现韩等人所描绘的愿景。在他们开创性的HotNet 13论文[62]中，重新推动了被动分解，其中分解逻辑/智能取决于客户端，并且远程资源仅尽可能快地服务请求[12，36，61，122，130]。被动分解促进了网络连接模型，其中内存、存储、DPU和ASIC直接连接到网络，并提供了与细粒度计算模型（如无服务器）更好的匹配[37，107]。它还使得系统设计者能够重新思考（I）用于发现和配置协议的网络协议（例如，弹射器结构[111]）；（II）用于分布式资源分配和访问的客户端和远程服务器之间的工作划分（例如，Clio[61]，DUA[123]）；以及（III）具有隔离、多路复用机制（例如，组卸载和存储器重新分配[12，77，93]）的卸载友好。

总结：在这项工作中，我们提出了一个消除CPU及其设计包袱的案例，并认为它的消除可以带来实质上的简单性，并提供性能/能量优势。我们设计和实现Hyperion的尝试就是朝着这个方向迈出的一步。

Hyperion

3.1硬件设计

在商业上，NIC和存储设备（例如NVM Express）可作为单独的PCIe设备提供。两者之间的通信需要通过PCIe根复合体与来自CPU（如果支持，例如NVMe控制器内存缓冲区（CMB）[21]）的P2P DMA进行控制协调，PCIe根复合体通常驻留在CPU复合体上（将其保持在循环中）。为了使DPU自给自足，Hyperion在FPGA板上运行带有NVMe控制器的PCIe根复合体，该控制器直接连接到100 Gbps网络。FPGA PCIe通道通过PCIe分叉连接（x16）到现成的NVMe存储设备。因此，对存储器的所有访问都通过FPGA进行。有了这样的设计，Hyperion现在拥有了一条从网络到FPGA再到存储设备的端到端硬件路径。端到端硬件路径可以专用于具有优化的网络传输（TCP、UDP、RDMA、HOMA[104]）、存储API（NVMoF[117]、i10 [68]、ReFlex [80]、KV-SSD [27]）的工作负载，FPGA上具有任意存储功能(压缩，指针跟踪，重复数据删除，或应用程序定义的代码)。

为什么选择FPGA？三个因素决定了FPGA的选择：

1. 特定于应用程序的可重构性：FPGA的使用允许我们重新配置硬件（深流水线、展开循环、数据并行、大型缓存），以实现特定于应用程序的逻辑的最佳可能实现。ASIC具有类似的优点，但需要较高的初始投资和制造成本。此外，由于越来越多的趋势是在附近放置数千个特定于工作负载的处理单元（PU）（例如，Cerebras[2]、Telsa Dojo[6]），因此PU和存储器（SRAM、DRAM或HBM）之间的距离至关重要。在这里，我们认为基于FPGA的设计提供了最佳的折衷方案。

2.  改进的FPGA系统软件支持：管理FPGA的主要挑战来自于使用硬件描述语言（HDL）仔细管理工作负载的流水线执行。随着高质量DSL[18，75，82，118]、操作系统外壳[84]和HDL编译器（hXDP[35]）的出现，为高数据速率（100+Gbps）生成高质量HDL变得更加经济实惠[53，92]。整个FPGA的编译和调试过程也得到了改进[95，136]。

3.  可预测的能效性能：与CPU和I/O设备不同，后者以细粒度的基于时间的统计多路复用（微秒到纳秒）为目标，以最大限度地提高资源利用率，而FPGA则以更粗糙的时间尺度（10-100毫秒）为目标，甚至是将资源分配给租户的空间多路复用。这种共享模型有助于构建高度可预测的执行流水线，一旦相关的比特流被发送到FPGA，电路就会在没有任何外部干扰的情况下运行特定的时钟频率[70，89]。FPGA的使用已被证明是节能的[35，112，116]，因为其能耗与活动和使用的可编程LUT以及工作频率成比例。未使用的逻辑元件不消耗任何能量，导致部署消耗10-20瓦，这比服务器级机器小一个数量级[70]。

除了FPGA的选择之外，Hyperion还将NVM Express（NVMe）用于块SSD，将以太网用于网络，以及将PCIe用于FPGA和SSD之间。这些选择取决于实用性和所需的工程努力。例如，选择PCIe而不是其他高性能本地互连（CXL、CAPI）或网络（TrueFabric[55]），可以随着工作负载需求的增加而修改。

3.2软件和编程

由于没有CPU和传统的操作系统，在Hyperion中使用提升的权限进行传统的资源管理来协调对共享资源的访问将是具有挑战性的。因此，我们必须重新协商硬件、编译器和应用程序之间的分工，让编译器发挥主导作用。编译器的角色在这里并不罕见。已经表明，编译器辅助设计可以帮助传统的操作系统角色，例如上下文切换[48，88，97]，内存虚拟化[126]，单级内存/存储[30，67]，并行[35]，虚拟化和多租户[75，138]。

使用这种以编译器为中心的方法，我们冒着VLIW处理器重复故障的风险。然而，我们认为有两个根本性的转变对我们有利。首先，特定于领域/工作负载的架构是常见的，并且相关的语言（例如，OpenCL，Chisel[18]）和编译器被广泛用作标准。在共同设计特定领域或特定工作负载的硬件/软件方面有重要的研究和商业利益。其次，与VLIW处理器不同，DPU(特别是FPGA驱动的)的目标不是为所有/任何工作负载提供性能，因此，限制了优化设计空间。例如，hXDP已经证明，使用简单语言（eBPF）的编译时启发（Bernstein条件）可以用于使用VLIW软核处理器的数据包处理工作负载的自动并行[35]。

受LLVM项目的启发，在本文中，我们认为FPGA编程需要使用独立于加速器的中间表达（IR）语言来解耦前端（应用程序逻辑）和后端（HDL代码）。IR可用于对程序的正确性和安全属性进行推理，并对指针调整和特权调用进行编译器辅助转换。由于三个关键原因，我们认为扩展Berkeley分组过滤器（eBPF）[40，99]语言是这种IR的合适匹配。首先，eBPF不依赖于特定的应用程序域，它用于网络[65，135]、跟踪[59]、缓存[58]、安全[74]和存储[20，28，85，141]。它还得到了健康成长的社区（Cilium，EBPF基金会）的支持，从而建立了专门知识和知识库。第二，由于eBPF指令集的简化特性，可以对其执行进行验证和推理。Linux内核已经附带了eBPF验证器[127]（具有简化的符号执行检查）。最后，eBPF支持多个硬件设备（如x86、ARM或FPGA）的高效代码生成（通过JITing），从而巩固了其作为独立于加速器的地位，统一了异构计算的IR[76]。请记住，这里我们对eBPF采取了更广泛的立场，其中Linux内核实现是eBPF执行环境的许多可能实现之一。例如，有用户空间BPF虚拟机[9]、检查器[57]和特定于应用程序的ISA扩展[35]。除了eBPF之外，我们还考虑P4，另一种用于网内加速（NIC和交换机）的流行编程语言。然而，P4程序是围绕数据包处理和网络抽象设计的。在有限的功能中（只有过滤和转发），有P4到eBPF编译器可用，尽管P4对于一般数据处理的通用性还有待探索。

Hyperion支持任何支持eBPF的编程语言作为前端。然后，它使用Clang/LLVM从前端生成eBPF IR。eBPF IR然后被传递到两个阶段的编译过程。在第一阶段，eBPF IR通过开源hXDP编译器进行并行和优化VLIW转换[17，35]。在第二阶段中，优化的eBPF IR通过eBPF-to-HDL编译器用于最终的HDL代码生成。与hXDP不同，Hyperion直接运行HDL代码，而不是作为FPGA上的VLIW软核处理器。

除了将应用程序提供的代码基本编译为HDL之外，还存在与以下方面相关的挑战：（I）安全的多租户执行；以及（II）数据中心资源的FPGA配置、管理和可访问性[123]。由于在FPGA中执行时没有主机系统资源(CPU或操作系统上)需要保持一致和安全，因此过去的许多设计选择都可以简化。我们建议利用FPGA资源的槽式切片[75]和编译器来进行工作负载划分[138]。Hyperion运行一个配置内核，该内核可以通过网络接收授权的FPGA位流，并为其分配切片。

3.3客户端接口和工作负载

为了提供可特殊化的客户端接口，Hyperion从Willow中获得灵感[121]，Willow开创了支持RPC的可编程SSD接口，其中用户提供应用程序端和SSD端RPC存根。这种灵活的设计可以支持网络和存储接口的任何所需的专门化。例如，我们可以构建能够支持Corfu共识协议[19，134]、块级NVMoF访问、NFS加速或应用程序提供的代码的线内碰撞/近数据执行（B+/LSM树搜索、压缩和插入、文件系统遍历、事务）的网络连接SSD[116，139]。在这里，我们可以利用客户端驱动的请求路由[91]和无共享的运行到完成数据路径[24]来提高性能。

我们主要关注Hyperion的三个应用程序类。首先，高容量应用程序（如fail2Ban[4]）检查和写入网络流量，并将身份验证/恶意数据记录到连接的SSD。此类应用程序必须在紧张的时间预算（每秒数以百万计的数据包）下处理大量的数据包数据。第二，对延迟敏感的应用程序，如网络指针追踪。在分解存储中，在B+树、扩展树、LSM树（在许多数据库、文件系统和键值存储中使用[109]）上的指针追踪导致多个网络RTT具有显著的性能下降[85]。最后，网络连接的SSD可以导出应用程序定义的高级容错，例如树、查找表[27]、分布式/共享日志[19，134]、原子写入[105]、并发附加[31]、缓存[58]以及并发数据结构和事务接口（类似于Boxwood[96]）。

这里的一个主要挑战是处理过程中多个功能的可组合性和FPGA上的状态管理。通常，与FPGA的存储集成是在块级完成的，以便对数据流进行无状态数据处理（如grep）。因此，需要适当的API和来将高级存储与FPGA/BPF上的有效状态管理集成，例如文件系统[28，116，119]、文件/数据格式集成[86，106]、数据缓存[58]、OOS调度（存储/网络资源的优先级共享）、检查点、去重复、加密等。我们正在为FPGA代码构建共享库等模块。

3.4现状

我们正在使用Xilinx Alveo U280板制作Hyperion原型，该板具有2x100 Gbps QSFP[1]。我们设计了一个PCIe cross overboard[46]，用于将4个NVMe设备连接到带电源的U280。

当加电并且FPGA JTAG自测试通过时，当前系统在没有任何CPU的情况下以独立模式启动。该板目前通过USB连接到主机系统进行编程，但是，我们正在开发一个操作系统外壳和网络上的控制路径，它也可以完全独立地对FPGA进行编程，通过FPGA的内部配置访问端口（ICAP）利用部分动态重新配置。我们选择使用B+树关键值存储作为Hyperion的首批应用程序之一。我们已经编写了一个XDP兼容的B+树，它在内核中的XDP路径（内存）上运行。在Hyperion上，树将其所有数据直接存储在NVMe设备上，并将通过网络提供get/put/delete请求。

我们硬件的原始延迟为：L2网络RTT~1µs，NVMe延迟为[5-8]µs。目前，我们不进行任何缓存，因此，所有的树访问都会导致对存储设备的访问。在此设置下，平均（预期）查找延迟为：O（1+（tree_height ×8）µsec））。根据过去使用网络包处理管道的经验，我们期望Hyperion支持每秒1百万次查找操作，尽管峰值性能取决于并行运行的PCIe通道、NVMe设备和FPGA内核的数量。在我们当前的编译过程中，B+树实现生成1000多个管道阶段。这是我们用工具链测试过的最大设计之一，它对FPGA上的资源可用性提出了挑战。尽管我们相信，即使是这种未经优化的B+树实现也可以适用于FPGA，并且有足够的优化空间来实现真正的多租户。

Hyperion 的原型使用 xilinx u280 fpga 和 nvme 设备，如图2和图3所示。

相关工作

Nider和Fedorova还质疑了系统中“最后一个CPU”的效用，并研究了系统管理总线的设计，以接管OS/CPU的职责[101]。表1显示了成对设备交互的努力，例如GPU与存储器[22，25，26，113，124]、GPU与网络[43，78，102]、加速器到/从存储器[13，15，16，90]、智能NIC[50，110，128]和网络存储访问[79，117]。用（1）网络 [35，53，132，142]以及（2）存储[116，119，121] 探索FPGA。使用Endance DAG卡[49]、Netronome[71]、Combo6[98]将BPF卸载到NIC/FPGA进行处理，但主要限于监控和流量塑形。FPGA辅助的KV存储考虑了网络和KV处理(内存)的紧密集成[32，38，69，89]以及NAND闪存的选择性集成(例如BlueDB和XilinxKV[33，137])。最接近Hyperion的设计灵感之一是LeapIO[90]，它将NVMe闪存与RDMA NIC和ARM SoC集成在一起。Hyperion和LeapIO有着相似的动机（成本、能源和性能效率），但是Hyperion可以避免LeapIO的许多设计复杂性（主机x86 CPU和ARM SoC的交互）。Hyperion的目标是更广泛的设计空间，我们考虑统一可重新配置的硬件（此处为FPGA）、网络传输（100 Gbps以太网）和存储（NVMe闪存）。这种统一提供了多种硬件/软件专业化认证，以支持多种工作负载需求。

讨论和反馈

Hyperion仍处于早期原型阶段。从系统社区，我们寻求对以下问题的反馈：

(1)  淘汰CPU是值得追求的目标吗？在本文中，我们提出了一个有争议的移除CPU的案例，我们相信，随着最近硬件和软件的进步，现在是重新评估CPU的作用及其带来的设计包袱的时候了。然而，我们有兴趣听取反驳意见。我们明白，除了技术之外，运营成本和复杂性可能会限制这一想法的实现。从无CPU设计中获得的性能、能源和封装效率达到什么水平才是值得的？消除CPU端中介还需要FPGA工具链、语言和编译器发挥更大的支持作用，这一作用以前由主机CPU和操作系统分担。FPGA工具链准备好了吗？

(2)  构建分布式Hyperion应用程序的合适客户端接口是什么？除了硬件和单个DPU之外，构建可在多个DPU上执行的分布式无CPU应用程序还需要哪种应用程序级接口/抽象？被动的资源分解将控制协调的责任放在客户端。多个客户端要么自己协调，要么使用外部服务[11，70]。但是，为了充分发挥Hyperion的潜力，应用程序在与Hyperion交互时还应减少客户端CPU/OS的参与（例如，使用RDMA或DPDK）。如何构建这种独立的、被动分解的DPU的分布式应用程序和可组合的服务生态系统？

(3)  多租户云中的运营复杂性？在数据中心、硬件和软件出现故障。租户不受信任。低效率和停机的成本很高。因此，如何确保Hyperion能够在FPGA中提供安全的多租户执行[140]？如何使用Hyperion减少微架构攻击？Hyperion的微架构资源是否可以或应该与租户明确管理，以确保与Hyperion DPU充分隔离[114]？

我知道你

在看

哦