Reexamining Direct Cache Access to Optimize I/O Intensive Applications for Multi-hundred-gigabit Networks

文章标题：重新审视直接缓存访问以优化面向数百吉比特网络I/O密集型应用
作者/机构：Alireza Farshin (KTH皇家理工学院), Amir Roozbeh (KTH皇家理工学院和爱立信研究院), Gerald Q. Maguire Jr. (KTH皇家理工学院), Dejan Kostić (KTH皇家理工学院)

A1 主要贡献

本文旨在研究缓存管理对I/O密集型应用性能的影响，特别关注数据包处理中的一个瓶颈：直接缓存访问（Direct Cache Access, DCA）。随着网络接口速率达到数百吉比特，内存访问成为商用硬件的主要性能瓶颈，充分利用靠近处理器的缓存变得至关重要。

核心问题：
在数百吉比特的网络速率下，传统通过主内存进行数据I/O的方式效率低下，因为访问主内存的延迟（约100ns）远高于处理一个小数据包的时间预算（约6.72ns at 100Gbps）。Intel处理器中的数据直接I/O技术（Data Direct I/O technology, DDIO）虽然允许I/O设备直接与处理器缓存通信，但其具体实现和性能特征鲜为人知，并且在高速率下可能成为新的瓶颈，导致所谓的“泄露DMA问题”（leaky DMA problem），即新到达的数据包会驱逐缓存中尚未处理或已处理的数据包。

研究目标：
本文的目标是通过经验性地逆向工程DDIO的实现细节，系统性地研究和理解Intel处理器中DCA的当前实现（即DDIO），评估其在100/200 Gbps速率下的有效性，识别其缺点，并提出一套优化指南，以实现性能隔离并提升在数百吉比特速率下的应用性能。

主要贡献：
本文的主要贡献如下：
1. 设计了一系列微基准测试，揭示了DDIO实现中鲜为人知的细节（§4）。
2. 在不同场景下广泛研究了DDIO的特性，并识别了其缺点（§5）。
3. 展示了在扩展时平衡核心间负载和调整DDIO容量的重要性（§6）。
4. 测量了多种应用（如Memcached、NVMe基准测试、NFV服务链）对DDIO的敏感性（§7）。
5. 证明了在以200 Gbps速率接收数据包时，绕过缓存的必要性和好处（§8）。
6. 讨论了从研究中获得的经验教训，这些经验对于优化接收数百吉比特速率流量并启用DDIO的系统至关重要（§9）。

A3 背景知识/关键Observation/设计原则

2. 直接缓存访问 (DCA)

传统DMA机制及其效率问题。将数据从I/O设备传输到处理器的标准方法是直接内存访问（DMA）。在此机制中，处理器向I/O设备提供一组内存地址（接收描述符），设备随后直接在主内存中读写数据，无需处理器介入。处理器通过中断或轮询得知新数据到达，然后将I/O数据从主内存取到其缓存中进行处理。对于出向流量，处理器通知I/O设备数据已准备好从主内存DMA到设备。传统DMA传输的主要源或目的地是主内存（如图1a所示），但数据最终需要加载到处理器缓存中才能处理。因此，这种方法在访问主内存次数（n个缓存行需要2n+5次访问【43，A. Kumar, R. Huggahalli, and S. Makineni. Characterization of Direct Cache Access on multi-core systems and 10GbE. 2009 IEEE 15th International Symposium on High Performance Computer Architecture】）、I/O数据访问延迟和内存带宽使用方面效率低下且成本高昂。随着链路速度的提高，这些低效率问题愈发严重。例如，在100 Gbps速率下，服务器处理小数据包的时间仅为6.72 ns，而每次访问主内存耗时约100 ns，成本高出15倍。

DCA的提出与演进。因此，将I/O数据直接放入处理器缓存比放入主内存更为理想。更快的I/O技术促使研究人员引入了直接缓存访问（DCA）【25，R. Huggahalli, R. Iyer, and S. Tetrick. Direct cache access for high bandwidth network I/O. 2005 32nd International Symposium on Computer Architecture (ISCA’05)】【42，A. Kumar and R. Huggahalli. Impact of Cache Coherence Protocols on the Processing of Network Traffic. 2007 40th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO 2007)】【43，A. Kumar, R. Huggahalli, and S. Makineni. Characterization of Direct Cache Access on multi-core systems and 10GbE. 2009 IEEE 15th International Symposium on High Performance Computer Architecture】。DCA利用PCIe事务层数据包处理提示（Transaction Layer Packet Processing Hint）【30，Intel Arria 10 Avalon-ST Interface with SR-IOV PCIe Solutions User Guide. 2019】，可以将部分I/O数据预取到处理器缓存中（如图1b所示）。这有望克服传统DMA的缺点，从而实现最大的I/O带宽并减少处理器停顿时间。尽管这种实现DCA的方式可以有效地预取所需的I/O数据部分（如描述符和包头），但由于整个数据包仍被DMA到主内存，因此在内存带宽使用方面仍然效率低下。此外，这还需要操作系统（OS）的干预以及I/O设备、系统芯片组和处理器的支持【1，Direct Cache Access (DCA). 2010】。为了解决这些限制并避免数据在主内存和处理器缓存之间来回传递，Intel重新设计了基于预取提示的DCA，引入了数据直接I/O技术（DDIO）【28，Intel Data Direct I/O Technology Overview. 2012】。

图1: 从I/O设备（例如NIC）传输数据的不同DMA方法。红色箭头显示了数据包到达处理核心所经过的路径。
图1: 从I/O设备（例如NIC）传输数据的不同DMA方法。红色箭头显示了数据包到达处理核心所经过的路径。

3. 数据直接I/O技术 (DDIO)

DDIO工作机制。Intel在Xeon E5家族中引入了DDIO技术。借助DDIO，I/O设备直接向末级缓存（LLC）或从LLC执行DMA，而不是系统内存（见图1c）。DDIO也被称为“写分配-写更新能力的DCA”（wauDCA）【45，Sheng Li, et al. FullStack Architecting to Achieve a Billion-Requests-PerSecond Throughput on a Single Key-Value Store Server Platform. 2016 ACM Trans. Comput. Syst.】，因为它使用此策略来更新n路组相联LLC中的缓存行，其中n个缓存行构成一个组。对于数据包处理应用，NIC可以通过LLC发送/接收RX/TX描述符和数据包本身，从而提高应用的响应时间和吞吐量。DDIO的工作方式如下【41，Maciek Konstantynowicz, et al. Benchmarking and Analysis of Software Data Planes. 2017】:
* 写入数据包。当NIC通过PCIe向LLC写入一个缓存行时，如果该缓存行已存在于任何LLC way中（称为PCIe写命中或写更新），DDIO会覆盖该缓存行。否则，该缓存行将在LLC中被分配，DDIO将数据写入新分配的缓存行（称为PCIe写未命中或写分配）。在后一种情况下，DDIO在分配缓存行时仅限于使用LLC的一小部分。可以通过处理器向这些缓冲区的地址写入来预热缓存，从而人为地增加这部分空间，然后DDIO执行写更新【16，Financial Services Industry (FSI) - Frequently Asked Questions. 2019】。
* 读取数据包。如果缓存行存在于任何LLC way中（称为PCIe读命中），NIC可以从LLC读取该缓存行。否则，NIC从系统内存中读取一个缓存行大小的数据块（称为PCIe读未命中）。

DDIO监控。为了监控DDIO及其与I/O设备的交互，Intel在其处理器中添加了uncore性能计数器【29，Intel Xeon Processor Scalable Memory Family Uncore Performance Monitoring. 2017】。Intel性能计数器监控（PCM）工具（例如pcm-pcie.x*）【86，Thomas Willhalm, et al. Intel Performance Counter Monitor - A Better Way to Measure CPU Utilization. 2017】可以计算PCIe写命中/未命中的次数（表示为ItoM事件）和PCIe读命中/未命中的次数（表示为PCIeRdCur事件）。

3.1 DDIO如何成为瓶颈？

泄露DMA问题。研究人员已经展示了一些DDIO无法提供预期好处的场景【11，Harsha Basavaraj. A case for effective utilization of Direct Cache Access for big data workloads. 2017】【41，Maciek Konstantynowicz, et al. Benchmarking and Analysis of Software Data Planes. 2017】【50，Patrick Lu. Performance Considerations for Packet Processing on Intel Architecture. 2017】【83，Amin Tootoonchian, et al. ResQ: Enabling SLOs in Network Function Virtualization. 2018 NSDI】。两种典型情况是，新传入的数据包反复驱逐LLC中先前DMA的数据包（即尚未处理和已处理的数据包）。因此，处理器必须从主内存而不是LLC加载尚未处理的数据包，并且NIC需要从主内存DMA已处理的数据包，从而失去了DDIO的好处。Tootoonchian等人将此问题称为“泄露DMA问题”【83，Amin Tootoonchian, et al. ResQ: Enabling SLOs in Network Function Virtualization. 2018 NSDI】。为缓解此问题，他们提出减少“在途”缓冲区（即描述符）的数量，以使所有传入的数据包都能容纳在用于I/O的LLC有限部分中。因此，性能隔离仅能通过CAT（缓存分配技术）实现。

减少描述符数量的局限性。不幸的是，由于链路速度的增加，减少RX描述符的数量只是一个临时解决方案。数百吉比特的NIC带来了新的挑战：
1. 数据包丢失。在亚百吉比特的链路速度下，减少RX描述符的数量可能不会导致高丢包率，但在≥100 Gbps时，由于处理时间预算紧张，丢包率会增加。例如，在100 Gbps下接收64字节数据包时，每额外花费约7 ns的停顿或处理/访问时间，就会导致另一个数据包被缓冲。当没有足够资源进行即时处理时，增加RX描述符的数量允许数据包被缓冲而不是被丢弃。处理延迟可能由中断处理、处理时间过长或数据包到达率突然增加引起【17，Intel Ethernet X520 to XL710 - Tuning the buffers: a practical guide to reduce or avoid packet loss in DPDK applications. 2017】；因此，数百吉比特网络必须有足够多的描述符才能避免丢包。
2. TX缓冲。使DDIO效率低下的一个场景是已处理数据包被驱逐。减少RX描述符的数量可能对需要少量TX描述符的系统有效，但对100-Gbps NIC则不然。不幸的是，事实上的DMA介质（即PCIe 3.0）存在一些传输限制【58，Rolf Neugebauer, et al. Understanding PCIe Performance for End Host Networking. 2018 SIGCOMM】。因此，数据包通常需要在计算机系统中缓冲一段时间才能被DMA到NIC。这种缓冲可以通过软件队列或增加TX描述符的数量来实现【35，Muthurajan Jayakumar. Data Plane Development Kit: Performance Optimization Guidelines. 2019】。不幸的是，这两种选择都增加了已处理数据包被驱逐的概率。
3. PAUSE帧。为减轻丢包，可以使用以太网流控制机制（如PAUSE帧），使数据包在网络中更早地被缓冲。然而，这些机制在延迟方面成本高昂，对于时间敏感的应用来说，不如丢包可取。本文测量显示，一个核心在100 Gbps下使用1024个RX和TX描述符转发数据包时，NIC在接收约8000万个数据包时会发送约17.9万个PAUSE帧。

动态减少与扩展的挑战。一种替代方案是当I/O引起的缓存驱逐增加时，动态减少对LLC的压力，例如通过减少RX突发大小。然而，这种反应式方法效果不佳。此外，随着处理器核心数量的增加和每核心LLC份额的减少（例如，Skylake中从2.5 MiB减少到1.375 MiB【55，David Mulnix. Intel Xeon Processor Scalable Family Technical Overview. 2017】），扩展核心数量也会导致“泄露DMA问题”，因为所有核心共享有限的DDIO空间。

本文的方法。为了克服这些挑战，本文通过经验性地研究和分析DDIO，以便更好地利用它。例如，图2表明，通过调整DDIO的容量，可以使用大量描述符实现合适的性能，这与Tootoonchian等人【83，Amin Tootoonchian, et al. ResQ: Enabling SLOs in Network Function Virtualization. 2018 NSDI】提出的使用有限描述符的方法（ResQ）形成对比。

图2: 使用更多的DDIO ways ("W") 使2个核心能够以100 Gbps的速率转发1500字节的数据包，同时使用更多的描述符，并实现更好或相似的尾部延迟。
图2: 使用更多的DDIO ways ("W") 使2个核心能够以100 Gbps的速率转发1500字节的数据包，同时使用更多的描述符，并实现更好或相似的尾部延迟。

A2 方法细节

4. 理解DDIO的细节

本节通过实验回答四个问题：1) LLC的哪一部分用于I/O？ 2) I/O如何与其他应用交互？ 3) 通过远程socket的DMA是否会污染LLC？ 4) 是否可以禁用/调整DDIO？

测试平台。实验使用表1配置的测试平台，运行Ubuntu 18.04.2（Linux内核4.15.0-54），主要使用Skylake服务器。使用FastClick【9，Tom Barbette, et al. Fast Userspace Packet Processing. 2015 ANCS】生成和处理数据包，工作负载包括真实的校园流量（混合大小数据包）和合成流量（固定大小数据包）。多核实验使用RSS【24，Ted Hudek. Introduction to Receive Side Scaling. 2017】分发数据包到不同队列（每核一队）。为提高测量准确性，实验运行在隔离的CPU socket上，并禁用了PAUSE帧。

Table 1: 我们的测试平台详情。每个案例中，NIC均为Mellanox ConnectX-5 VPI。

4.1 占用情况

DDIO使用的LLC ways。Intel最初声称DDIO仅使用10%的LLC【28，Intel Data Direct I/O Technology Overview. 2012】，但未明确是哪些部分。近期技术报告指出DDIO默认使用LLC的一个子集ways，通常是两个【41，Maciek Konstantynowicz, et al. Benchmarking and Analysis of Software Data Planes. 2017】【72，Roman Sudarikov and Patrick Lu. Hardware-Level Performance Analysis of Platform I/O. 2018】。为了确定这些ways是否固定，我们设计了一个实验，将一个I/O密集型应用（DPDK L2转发，接收1024-B数据包，速率约82 Gbps，使用4096个RX描述符）和一个缓存敏感型应用（Splash-3套件的water_nsquared）共同运行。

实验设计与结果。两个应用运行在不同核心上，并使用CAT为每个核心分配不同的缓存ways。I/O应用分配两个固定的ways，缓存敏感应用分配两个可变的ways。为避免内存带宽争用，使用MBA技术将每个核心的内存带宽限制为40%。实验中，缓存敏感应用被分配的两个ways从LLC的最左侧开始，逐步向右移动，同时测量I/O应用的LLC未命中数。如图3b所示，结果显示在两个区域存在干扰。第一个区域（如图3b中的0x0C0）是由于两个应用的代码/数据干扰。第二个区域（如图3b中的0x003）无法用同样理由解释，因为此时I/O应用被限制使用其他ways（0x0C0）。由于CPU socket被隔离，没有其他应用能引起缓存未命中。CAT只缓解代码/数据引起的争用，而不缓解DDIO。因此，我们得出结论，第二次干扰很可能是由I/O引起的，这意味着DDIO使用了LLC中最右侧的两个ways（位掩码为0x003）。

图3: 当缓存敏感应用使用不同的LLC ways时，一个I/O应用和一个缓存敏感应用（使用parsec_native配置以引起高缓存未命中率）的干扰情况。最右侧的上升显示了与DDIO ways的争用。
图3: 当缓存敏感应用使用不同的LLC ways时，一个I/O应用和一个缓存敏感应用（使用parsec_native配置以引起高缓存未命中率）的干扰情况。最右侧的上升显示了与DDIO ways的争用。

4.2 I/O争用

争用场景。CAT是确保性能隔离和缓解缓存争用的成熟机制，但由于DDIO使用固定的两个LLC ways，CAT可能无法完全保证性能隔离。争用可能发生在两种常见场景：
1. I/O vs. 代码/数据。当一个应用被限制使用DDIO也使用的ways时，为DDIO分配的缓存行可能会驱逐任何应用（I/O或非I/O应用）的代码/数据。Tootoonchian等人提出的ResQ框架【83，Amin Tootoonchian, et al. ResQ: Enabling SLOs in Network Function Virtualization. 2018 NSDI】通过仅使用90%的LLC来避免干扰DDIO的保留空间。我们的实验（图3b右侧）显示，当一个缓存饥渴型应用与DDIO重叠时，I/O应用的缓存未命中数增加了约2.5倍。反过来，我们也测量了争用对缓存饥渴型应用的影响，如图4所示，其缓存未命中数同样受到不利影响。因此，任何应用与DDIO ways重叠都会降低双方性能。有趣的是，I/O驱逐代码/数据发生在使用最左侧两个ways时（图4中的0x600），而代码/数据驱逐I/O则发生在最右侧两个ways时（图3b中的0x003）。这表明CAT对I/O和代码/数据到ways的映射可能不是双射函数，即 f: code/data → Ways 不等同于 g: I/O → Ways。
2. I/O vs. I/O。当多个I/O应用通过CAT相互隔离时，它们仍可能无意中争夺分配给DDIO的固定ways。

安全影响。由于DDIO使用固定的两个ways，这可能被用于扩展微架构攻击（如NetCAT【44，Michael Kurth, et al. NetCAT: Practical Cache Attacks from the Network. 2020 S&P】和Packet Chasing【76，Mohammadkazem Taram, et al. Packet Chasing: Spying on Network Packets over a Cache Side-Channel. 2019】【77，Mohammadkazem Taram, et al. Packet Chasing: Observing Network Packets over a Cache Side-Channel. 2020 ISCA】）来提取I/O数据中的有用信息。

图4: 缓存敏感应用和I/O应用的干扰。Y轴显示缓存敏感应用的总缓存未命中数。缓存敏感应用使用较轻的配置（即ddio_sim），其引起的缓存未命中数少于I/O应用。
图4: 缓存敏感应用和I/O应用的干扰。Y轴显示缓存敏感应用的总缓存未命中数。缓存敏感应用使用较轻的配置（即ddio_sim），其引起的缓存未命中数少于I/O应用。

4.3 通过远程Socket的DMA

DDIO的Socket本地性。根据Intel的说法【16，Financial Services Industry (FSI) - Frequently Asked Questions. 2019】【32，IO Issues: Remote Socket Accesses. 2019】，DDIO的当前实现仅影响本地socket。如果一个核心访问连接到远程socket的I/O设备的数据，数据必须通过核间互连（如QPI或UPI）。我们通过实验验证了这一点，将NIC连接到远程socket并重复§4.2的实验。结果显示，I/O缓存行并未影响任何一个应用的缓存未命中数，这意味着通过UPI链路传入的数据包不会最终进入本地LLC。此外，I/O应用的缓存未命中数急剧增加，比在本地socket无争用时高出20倍。因此，DDIO对远程socket无效，但会污染连接到NIC的那个socket上的LLC。

4.4 调整占用和禁用DDIO

通过MSR调整DDIO容量。虽然文档【20，Jeff Gilbert and Mark Rowland. The Intel Xeon Processor E5 Family: Architecture, Power Efficiency, and Performance. 2012】【72，Roman Sudarikov and Patrick Lu. Hardware-Level Performance Analysis of Platform I/O. 2018】提到DDIO默认使用两个ways，但未提及是否可以增减。一个鲜为人知的模型特定寄存器（MSR），名为“IIO LLC WAYS”，地址为0xC8B*，在一些在线资源中被讨论过【64，PCIe Bandwidth Drops on Skylake-SP. 2019】【79，Temporary PCIe Bandwidth Drops on Haswell-v3. 2019】。在Skylake上，此寄存器的默认值为0x600（设置了两位）。虽然这些位不能被取消设置，但可以设置额外的位，我们CPU上此寄存器的最大值为0x7FF（设置了11位，与LLC ways数量相同）。

调整效果验证。为了验证该MSR寄存器的效果，我们测量了在使用不同IIO LLC WAYS值时的PCIe读/写命中率。实验中，一个I/O应用以100 Gbps处理1024 B数据包，使用4096个RX描述符。图5显示，增加该MSR寄存器的值会导致更高的PCIe读/写命中率。这表明增加该寄存器的值可以提高系统处理高速率数据包的能力。我们推测，该寄存器的值与DDIO使用的LLC比例正相关。我们假设设置的位数指定了DDIO使用的ways数量。

图5: 调整IIO LLC WAYS寄存器可提高PCIe读/写命中率。此实验中实现的吞吐量为82-86 Gbps。
图5: 调整IIO LLC WAYS寄存器可提高PCIe读/写命中率。此实验中实现的吞吐量为82-86 Gbps。

禁用DDIO。DDIO是Intel虚拟化技术（Intel VT）的一部分，因此可以在某些供应商的BIOS中启用/禁用【16，Financial Services Industry (FSI) - Frequently Asked Questions. 2019】【23，How to disable Data Direct I/O (DDIO) on Intel Xeon E5? 2019】【88，Xeon E5 disable DDIO in OS? 2019】。根据文献【44，Michael Kurth, et al. NetCAT: Practical Cache Attacks from the Network. 2020 S&P】【72，Roman Sudarikov and Patrick Lu. Hardware-Level Performance Analysis of Platform I/O. 2018】，DDIO可以全局禁用（通过设置“iiomiscctrl”寄存器中的Disable_All_Allocating_Flows位）或按根PCIe端口禁用。我们为FastClick实现了一个名为DDIOTune的元素，可以启用/禁用/调整DDIO。

5. DDIO的特性分析

本节利用DDIO的调整能力，详细考察其在不同场景下的性能，旨在揭示DDIO何时成为瓶颈以及何时调整DDIO至关重要。我们研究了系统参数（RX描述符数量、核心数、处理时间）和工作负载特性（数据包大小和速率）对DDIO性能的影响。所有测量在Skylake和Haswell微架构上均进行了20次，行为一致，为简洁起见，仅讨论Skylake的结果。

5.1 数据包大小和RX描述符

描述符数量与包大小的影响。§3.1讨论了大量RX描述符对DDIO性能的负面影响。本节通过查看不同RX描述符数量和不同数据包大小下的PCIe读/写命中率来继续这一讨论。图6显示了PCIe写命中率的实验结果。当数据包大于512 B时，PCIe读/写命中率随着RX描述符数量的增加而单调下降。具体来说，即使使用相对较少的RX描述符（128个），发送1500-B的数据包也会导致PCIe读和写命中率出现10%的未命中。此外，将RX描述符数量增加到4096个，使DDIO的命中率降至约40%，这意味着60%的数据包需要缓存分配，并且必须从主内存而不是LLC被DMA回NIC。

图6: 在单个核心以最大可能速率转发数据包时，增加描述符数量和/或数据包大小会对2-way DDIO的性能产生负面影响。我们移除了64-B和128-B数据包的结果，因为它们的行为与256-B数据包相似。
图6: 在单个核心以最大可能速率转发数据包时，增加描述符数量和/或数据包大小会对2-way DDIO的性能产生负面影响。我们移除了64-B和128-B数据包的结果，因为它们的行为与256-B数据包相似。

图7: 由于NIC和PCIe的限制，增加数据包大小会降低到达率，即每秒接收/处理的数据包数量。请注意，当只有一个核心转发数据包时，我们的测试平台无法超过90 Gbps。
图7: 由于NIC和PCIe的限制，增加数据包大小会降低到达率，即每秒接收/处理的数据包数量。请注意，当只有一个核心转发数据包时，我们的测试平台无法超过90 Gbps。

意外的I/O驱逐。在某些情况下（例如图6中1500-B数据包和128个RX描述符），注入的数据大小小于DDIO容量（187.5 KiB < 4.5 MiB）。即使考虑到TX描述符和FastClick的软件队列，该工作负载的最大缓存足迹也约为2 MiB。然而，DDIO仍然经历了约10%的未命中。我们认为这种行为可能是因为应用无法使用全部DDIO容量，原因在于(i) 未公开的缓存替换策略和/或(ii) 缓存的复杂寻址【15，Alireza Farshin, et al. Make the Most out of Last Level Cache in Intel Processors. 2019 EuroSys】，导致多个缓冲区可能被加载到同一个缓存组中。

5.2 数据包速率和处理时间

数据包速率的影响。§5.1表明，当一个核心以100 Gbps进行最少处理时，DDIO性能极差。接下来，我们关注前一个实验的最坏情况（发送1500-B数据包，4096个RX描述符），同时改变数据包速率。为达到100 Gbps，我们使用两个核心。图8显示，PCIe读命中率在达到98 Gbps之前表现相对较好。然而，PCIe写命中率结果表明，在大多数吞吐量下，由于空间不足，DDIO必须为25%的数据包持续在LLC中分配缓存行。吞吐量超过75 Gbps会加剧此问题。

图8: 当2个核心使用4096个RX描述符转发1500-B数据包时，增加数据包速率会对PCIe指标产生负面影响。PCIe写指标更容易退化。
图8: 当2个核心使用4096个RX描述符转发1500-B数据包时，增加数据包速率会对PCIe指标产生负面影响。PCIe写指标更容易退化。

处理时间的影响。到目前为止，我们分析了核心执行最少处理时的DDIO性能。现在，我们分析更计算/内存密集型I/O应用的DDIO性能。我们通过多次调用std::mt1993随机数生成器来改变每个数据包的计算量。图9展示了增加每包处理时间对PCIe指标和实现吞吐量的影响。结果表明，增加处理时间会轻微提高PCIe读命中率，直到约60次调用（400个周期）。这是因为增加处理使应用变得不那么I/O密集，应用以较慢的速度向NIC提供缓冲区。然而，增加处理会导致可用处理能力（核心数）成为瓶颈，从而大幅降低吞吐量。因此，DDIO性能在应用受I/O限制时最为重要，而不是受CPU/内存限制。

图9: 使应用更具计算密集性会带来更好的PCIe指标，但吞吐量更低。除了转发数据包，两个核心在以100 Gbps接收1500-B数据包（总共4096个RX描述符）时调用一个虚拟计算。
图9: 使应用更具计算密集性会带来更好的PCIe指标，但吞吐量更低。除了转发数据包，两个核心在以100 Gbps接收1500-B数据包（总共4096个RX描述符）时调用一个虚拟计算。

5.3 核心数量和DDIO容量

核心数量扩展的影响。当处理能力限制应用性能时，系统应向上/向外扩展。然而，这种扩展会影响DDIO的性能。图10显示，当应用是I/O密集型时，增加核心数量会提高PCIe读/写命中率，因为它增加了TX队列数量并更快地消耗LLC中排队的数据包。然而，超过某个点（在我们的测试平台中是四个核心）后，增加核心数量会导致缓存中更多的争用，因为每个核心都独立地将数据包加载到有限的DDIO容量中。最终，扩展核心数量，即使使用少量RX描述符，也会导致与使用大量描述符相同的“泄露DMA问题”。

图10: 对于I/O密集型应用，增加核心数量并不总能改善PCIe指标。不同数量的核心以100 Gbps转发1500-B数据包，每核心256个RX描述符。
图10: 对于I/O密集型应用，增加核心数量并不总能改善PCIe指标。不同数量的核心以100 Gbps转发1500-B数据包，每核心256个RX描述符。

DDIO容量扩展的影响。图11显示了1、2和4个核心在改变DDIO ways数量时的PCIe指标。比较不同核心数/DDIO ways下的DDIO性能，我们得出结论，增加DDIO容量对PCIe指标的改善与增加核心数类似。因此，当应用的瓶颈不是处理能力或TX队列数量时，增加DDIO容量比增加核心数更有益。除非扩展能高效进行，否则一些核心可能会接收比其他核心更多的数据包，导致性能下降。

图11: 在以100 Gbps速率转发1500-B数据包（总共4096个RX描述符）时，增加DDIO ways数量可以产生与增加处理核心数量相似的积极效果。PCIe读命中率表现出与PCIe写相似的行为。
图11: 在以100 Gbps速率转发1500-B数据包（总共4096个RX描述符）时，增加DDIO ways数量可以产生与增加处理核心数量相似的积极效果。PCIe读命中率表现出与PCIe写相似的行为。

A7 补充细节

6. 应用级性能指标

PCIe指标与应用性能的关联。前一节表明，增加链路速度、数据包大小、描述符和核心数量会降低PCIe读/写命中率。这些指标间接影响应用性能，但其关联性取决于应用特性。例如，一个需要整个DMA数据的应用会受到低PCIe写命中率的严重影响，而一个只需部分数据的应用受影响较小。图2展示了后一种情况，即应用仅访问包头，增加描述符数量（导致PCIe命中率降低）仍会负面影响99%分位延迟。

有状态服务链实验。为了评估增加DDIO容量的效果，我们选择了一个由路由器、网络地址端口转换器（NAPT）和轮询负载均衡器（LB）组成的有状态服务链。我们将路由器的路由表卸载到NIC，仅在软件中处理有状态任务（NAPT+LB）。我们为校园流量生成了2423条IP过滤规则，并使用DPDK的Flow API技术【31，Intel Ethernet Flow Director and Memcached Performance. 2014】将其卸载到Mellanox NIC。为了检验负载不平衡的影响，我们生成了两组规则，一组采用轮询方式，另一组是负载感知型。负载感知方法导致的最大不平衡比为2.78倍，而轮询方式为1.69倍。

负载不平衡对DDIO调优效果的影响。图12显示了该服务链在不同负载均衡方法下的99%分位延迟。当负载不平衡较高时，增加DDIO容量将99%分位延迟降低了约21%。然而，当负载不平衡较低时，这些改进减少到约2%。较高的负载不平衡意味着某个核心接收更多数据包，其中一些可能在LLC中排队时被驱逐。因此，实现良好的负载均衡对于充分利用DDIO至关重要。

图12: 当负载不平衡因子较高时，应仔细调整DDIO。结果显示了18个核心在100 Gbps下处理混合大小数据包时，一个有状态网络功能的99%分位延迟。负载感知（较高不平衡）和轮询（较低不平衡）实验的吞吐量分别为94 Gbps和97 Gbps。
图12: 当负载不平衡因子较高时，应仔细调整DDIO。结果显示了18个核心在100 Gbps下处理混合大小数据包时，一个有状态网络功能的99%分位延迟。负载感知（较高不平衡）和轮询（较低不平衡）实验的吞吐量分别为94 Gbps和97 Gbps。

7. DDIO是否总是有益？

应用对DDIO的敏感性分析。上一节表明，为I/O密集型网络功能调整DDIO可以改善性能。然而，这些结果不能一概而论，因为改进高度依赖于应用的特性。为了研究这一点，我们通过启用/禁用DDIO来测量不同应用对它的敏感性。表2显示了五种应用/基准测试的结果：(i) DPDK实现的Memcached【5，Seastar. 2019】，(ii) NVMe基准测试工具fio【4，Flexible I/O Tester (fio). 2019】，(iii) L2转发应用，(iv) 在软件中执行IP过滤的有状态服务链，以及(v) §6中使用的带轮询卸载的有状态服务链。

敏感性定义与结果。如果对应用性能的最大影响≤5%，我们定义敏感性为“低”。结果表明，不同应用对DDIO的敏感度不同。最敏感的应用是L2转发，它是这些应用中最I/O密集的，并且可以以线速运行。一些应用（如Memcached）从DDIO中获益较少，因为它们的性能可能受其他瓶颈的限制。这一发现可被系统开发者用于在多租户环境中优化系统，其中多个I/O应用共存。

Table 2: 不同应用对DDIO的敏感性变化。

8. DCA的未来方向

当前DDIO的局限性。调整DDIO占用率虽能显著提升某些应用性能，但这只是临时方案。原因有二：(i) I/O只是数据包处理的一部分，许多网络应用需要大量缓存用于代码/数据；(ii) DDIO基于way，在现代Intel处理器中分区粒度较粗。这些因素加上处理器每核心LLC减小的趋势，使得当前DCA实现成为实现低延迟服务的瓶颈。

未来DCA的设计方向。因此，DCA需要以更小的缓存份额提供更好的性能。未来DCA的可能方向/提议包括：
1. 细粒度放置：采用CacheDirector【15，Alireza Farshin, et al. Make the Most out of Last Level Cache in Intel Processors. 2019 EuroSys】的方法（将数据包发送到适当的LLC切片），并仅将相关部分发送到L2、L1缓存或CPU寄存器【26，Stephen Ibanez, et al. The Case for a Network Fast Path to the CPU. 2019 HotNets】。
2. 选择性DMA/DCA：仅将数据包的相关部分DMA到缓存，其余部分缓冲在主内存、NIC或架顶交换机中。
3. I/O隔离：扩展CAT以包括I/O优先级，类似于代码和数据优先级（CDP）技术【60，Khang T Nguyen. Code and Data Prioritization Introduction and Usage Models in the Intel® Xeon® Processor E5 v4 Family. 2016】，以减轻I/O争用。

8.1 绕过缓存

绕过缓存的必要性。§3.1解释了减少描述符数量可以防止不必要的内存访问，但这在高链路速率下会增加丢包和PAUSE帧。因此，未来的DCA技术应更有效地执行缓存注入：如果会导致I/O驱逐，则不应将DMA导向缓存；将数据包缓冲在本地内存（成本仅几百纳秒）比丢弃或在先前节点排队更可取。在需要性能隔离的多租户场景中，绕过缓存也很有益。例如，低优先级或对DDIO不敏感的应用可以绕过缓存，为高优先级或高敏感度应用腾出空间。

评估。为了评估绕过缓存的好处，我们使用两种方法：(i) 禁用DDIO和(ii) 利用通过远程socket的DMA（见§4.3）。我们建立了一个200-Gbps的测试平台（见图13）。我们在第一个socket上运行两个L2转发应用实例，每个实例使用4个核心和一块NIC。我们假设其中一个应用优先级更高，并测量其在五种场景下的延迟：(i) 无低优先级应用；(ii) 低优先级应用通过2-way DDIO污染缓存；(iii) 低优先级应用通过4-way DDIO污染缓存；(iv) 低优先级应用通过远程socket DMA绕过缓存；(v) 低优先级应用通过禁用DDIO绕过缓存。

结果。图14显示了高优先级应用的99%分位延迟。结果表明，通过远程socket绕过缓存（场景iv）实现了与无低优先级应用时（场景i）相同的延迟。然而，当两个应用都通过DDIO接收流量时（场景ii），99%分位延迟恶化了约30%。我们观察到，绕过缓存与增加DDIO容量（场景iii vs. iv）具有相同的好处。此外，比较场景(iv)和(v)表明，禁用DDIO会轻微污染缓存（可能是描述符仍在使用DDIO）。因此，我们得出结论，绕过缓存可以减少性能可变性并实现更好的性能隔离。在迈向200 Gbps时，调整DDIO容量显然是必要的。

图13: 实现200 Gbps的接收端设置。在右侧设置中，第二块NIC连接到远程socket。它通过UPI链接直接将数据包发送到主内存。
图13: 实现200 Gbps的接收端设置。在右侧设置中，第二块NIC连接到远程socket。它通过UPI链接直接将数据包发送到主内存。

图14: 在200 Gbps下绕过缓存和调整DDIO可减轻I/O争用，并将高优先级应用的尾部延迟提高多达30%。场景：(i) 100 Gbps无争用；(ii) 200 Gbps下有争用；(iii) 200 Gbps下调整DDIO；(iv) 通过远程socket绕过缓存；(v) 通过禁用DDIO绕过缓存。接收端的总实现吞吐量写在条形图上。
图14: 在200 Gbps下绕过缓存和调整DDIO可减轻I/O争用，并将高优先级应用的尾部延迟提高多达30%。场景：(i) 100 Gbps无争用；(ii) 200 Gbps下有争用；(iii) 200 Gbps下调整DDIO；(iv) 通过远程socket绕过缓存；(v) 通过禁用DDIO绕过缓存。接收端的总实现吞吐量写在条形图上。

9. 经验教训：优化指南

总结发现与指南。本节总结了我们的关键发现，可帮助系统设计者/开发者为他们的应用优化DDIO。我们的研究揭示了：
* DDIO注入数据的LLC位置（§4.1）。
* 将应用的代码/数据与I/O共置在缓存中可能会对其性能产生负面影响（§4.2）。
* DDIO行为如何随不同系统参数和工作负载特性而变化（§5）。
* 如果应用受I/O限制，过度增加核心可能会降低其性能（图10）。
* 如果应用受I/O限制，仔细调整DDIO容量可以提高其性能，并可能达到与增加更多核心相同的改进效果（图11）。
* 如果应用开始变为CPU限制，增加更多核心可以提高其吞吐量，但必须平衡核心间负载以最大化DDIO的好处（图12）。
* 如果应用是真正的CPU/内存限制，DDIO调整效率较低（图9）。然而，将无法及时处理的传入请求/数据包缓冲在DRAM中可能是有益的，而不是让NIC发出PAUSE帧或丢弃数据包。
* 速率超过约75 Gbps可能导致DDIO成为瓶颈（图8）。因此，绕过缓存以实现性能隔离至关重要。可以为低优先级流量或不从DDIO中受益的应用绕过缓存（§8.1）。
* 不同应用对DDIO的敏感度不同（§7）。识别此级别对于更有效地利用系统资源、提供性能隔离和提高性能至关重要。

A4 实验环境

  • 数据集/工作负载：
    • 真实流量：使用一个校园网络流量跟踪（混合大小数据包）。
    • 合成流量：使用固定大小（64B, 128B, 256B, 512B, 1024B, 1500B）的数据包。
    • 应用基准：
      • DPDK实现的Memcached，用于键值存储测试。
      • fio，用于NVMe存储基准测试。
      • L2转发，作为I/O密集型网络功能。
      • 有状态NFV服务链，由路由器、NAPT和负载均衡器组成，用于评估更复杂的网络功能。
  • 模型架构：不涉及特定AI模型。网络功能以“运行至完成”（run-to-completion）模型实现。
  • 硬件配置：
    • CPU/平台：
      • Skylake服务器：2x Intel Xeon Gold 6140 CPU @ 2.30GHz (18 cores, 24.75 MiB LLC, 11-way set-associative), 128 GiB DDR4 RAM.
      • Haswell服务器：2x Intel Xeon E5-2699 v3 CPU @ 2.30GHz (18 cores, 45 MiB LLC, 20-way set-associative), 128 GiB DDR4 RAM.
    • GPU：未使用。
    • 网络：Mellanox ConnectX-5 VPI 网卡 (100GbE)。
    • 存储：4x 1024-GB Toshiba NVMe (KXG50PNV1T02) SSDs。
    • 连接：CPU socket隔离，PAUSE帧禁用。
  • 软件配置：
    • 操作系统：Ubuntu 18.04.2 (Linux kernel 4.15.0-54)。
    • 代码/库：
      • 使用FastClick框架进行数据包生成和处理。
      • 部分应用基于DPDK实现。
      • 使用RSS (Receive Side Scaling) 在多核间分发数据包。
    • 工具：
      • 实验运行使用Network Performance Framework (NPF)。
      • 性能监控使用Intel Performance Counter Monitor (PCM)。

A4 实验结果

本文通过一系列微基准测试和应用级实验，系统地揭示了Intel DDIO的特性、瓶颈和优化方法。
* DDIO的LLC占用：实验证实，在Skylake处理器上，DDIO默认使用固定的两个最右侧LLC ways（位掩码0x003）。（§4.1, 图3）
* I/O争用：与DDIO ways重叠的缓存敏感型应用会导致双方性能下降（缓存未命中增加约2.5倍）。CAT无法完全隔离此争用。（§4.2, 图4）
* DDIO的Socket本地性：DDIO仅在本地CPU socket生效。通过远程socket的DMA会绕过本地LLC，但会污染远程socket的LLC，并导致性能大幅下降（缓存未命中增加20倍）。（§4.3）
* DDIO的可调优性：通过修改MSR寄存器IIO LLC WAYS（地址0xC8B），可以增加DDIO使用的LLC ways数量，从而显著提高PCIe读/写命中率。（§4.4, 图5）
* 参数对DDIO性能的影响：
* 增加RX描述符数量和数据包大小会降低DDIO性能（命中率下降）。例如，使用4096个描述符处理1500B数据包时，命中率降至约40%。（§5.1, 图6）
* 当吞吐量超过75 Gbps时，DDIO开始成为瓶颈。（§5.2, 图8）
* 增加每包处理时间会使应用变为CPU密集型，从而改善DDIO的PCIe指标，但会牺牲吞吐量。这表明DDIO对I/O密集型应用更关键。（§5.2, 图9）
* 扩展性分析：
* 增加核心数量在一定程度上能提升I/O密集型应用的DDIO性能，但超过一个阈值（如4核）后会因争用加剧而导致性能下降。（§5.3, 图10）
* 增加DDIO容量可以达到与增加核心数相似的性能提升效果，是处理I/O瓶颈的有效替代方案。（§5.3, 图11）
* 应用级性能：
* 对于有状态网络功能，调整DDIO容量可以在高负载不平衡情况下将99%分位延迟降低约21%。（§6, 图12）
* 不同应用对DDIO的敏感度差异很大。L2转发等I/O密集型应用高度敏感（性能提升28%），而Memcached等应用则不敏感。（§7, 表2）
* 200Gbps下的性能优化：在200Gbps速率下，I/O争用会导致高优先级应用的尾部延迟增加30%。通过让低优先级应用绕过缓存（例如使用远程socket DMA），可以完全消除这种争用，恢复性能。（§8.1, 图14）

A5 结论

DCA技术旨在提升网络应用的性能。然而，本文系统地表明，Intel处理器中DCA的最新实现（即DDIO）在链路速度不断增加的背景下已无法满足需求。我们证明了需要更好的I/O管理来满足未来网络严苛的延迟要求。我们的主要目标是强调，网络性能现在比以往任何时候都更紧密地与当前硬件的能力耦合。因此，只有通过以下方式才可能实现时间关键的数百吉比特网络：(i) 对硬件进行日益完善且文档化的控制，以及 (ii) 改进的整体系统设计优化。