主机网络堆栈的开销研究：了解现有网络堆栈中的CPU效率低下

65∼–了解主机网络堆栈开销蔡启哲康奈尔大学舒巴姆·乔杜里康奈尔大学米胡尔·武帕拉帕蒂康奈尔大学摘要黄载贤康奈尔大学Rachit Agarwal康奈尔大学1介绍传统的终端主机网络堆栈由于其不可持续的CPU开销而难以跟上快速增长的数据中心访问链路带宽。受此启发，我们的社区正在探索未来网络堆栈的多种解决方案：从Linux内核优化到部分硬件卸载，再到清理用户空间堆栈，再到专门的主机网络硬件。这些解决方案所探索的设计空间将受益于对现有网络堆栈中CPU效率低下的详细了解。本文介绍了100Gbps接入链路带宽的Linux内核网络堆栈性能的测量和见解。我们的研究表明，这种高带宽的链接，再加上相对停滞的技术趋势，为其他主机资源（如。核心速度和计数、高速缓存大小、NIC缓冲区大小等），标志着主机网络堆栈瓶颈的根本转变。例如，我们发现单个核心不再能够以线速率处理数据包，从内核到接收器处的应用程序缓冲区的数据复制此外，带宽延迟乘积的增加超过了高速缓存大小的增加，导致NIC和CPU之间的DMA管道效率低下最后，我们发现，在现有的操作系统中，传统的网络堆栈和CPU处理器的松耦合设计成为跨核心扩展网络堆栈性能的限制因素。基于我们的研究的见解，我们讨论了未来的操作系统，网络协议和主机硬件的设计的影响CCS概念• 网络→传输协议;网络性能分析;数据中心网络; ·硬件→网络硬件;关键词数据中心网络、主机网络堆栈、网络硬件ACM参考格式：Qizhe Cai ， Shubham Chaudhary ， Midhul Vuppalapati ， JaehyunHwang，and Rachit Agarwal. 2021.了解主机网络堆栈开销。在ACMSIGCOMM 2021会议（SIGCOMMDylan Evans，USA.ACM，美国纽约州纽约市，13页。https：//doi. 电话：+86-10 - 88888888传真：+86-10 - 88888888允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取复制，或重新发布，张贴在服务器上或重新分发到列表 ， 需 要 事 先 特 定 的 许 可 和 / 或 费 用 。 请 求 权 限 请 发 邮 件 至permissions@acm.org。SIGCOMM© 2021计算机协会。ACM ISBN 978-1-4503-8383-7/21/08。- 是的- 是的十五块https://doi.org/10.1145/3452296.3472888摩尔定律的减速、Dennard扩展的终结以及高带宽链路的快速采用，使传统主机网络堆栈处于崩溃的边缘，而数据中心访问链路带宽（以及由此产生的数据包处理的计算需求）在过去几年中增加了410，基本上所有其他主机资源的技术趋势（包括核心速度和数量、高速缓存大小、NIC缓冲区大小等）在很大程度上停滞不前。因此，设计CPU高效的主机网络堆栈的问题已经成为最重要的问题，我们的社区正在探索各种解决方案，包括Linux网络堆栈优化[11，12，21，24，32，41]，硬件卸载[3，6，9，16]，RDMA [31，34，43]，干净的用户空间网络-工作栈[4，27，30，33，36]，甚至是专用的主机网络硬件[2]。这些解决方案所探索的设计空间将受益于对传统Linux网络堆栈的CPU效率低下的详细理解建立这样的理解是困难的，因为Linux网络堆栈不仅庞大而复杂，而且还包括许多紧密集成到端到端数据包处理管道中的组件。最近的几篇论文对短流的Linux网络堆栈开销进行了初步分析[21，30，32，38，40]。由于两个原因，这不能提供一个完整的画面。首先，对于数据中心网络，众所周知，绝大部分数据包含在长流中[1，5，28];因此，即使有许多短流，大部分CPU周期也可能花费在处理来自长流的数据包上。第二，数据中心工作负载不仅包含排除的短流或长流，而且还包含由各种流量模式组成的不同流量大小的混合物;正如我们将展示的那样，CPU特性会随着流量模式和流量大小的混合而发生显着变化。本文介绍了100Gbps接入链路带宽的Linux内核网络堆栈性能的测量和见解我们的主要发现是：高带宽链路导致性能瓶颈从协议处理转移到数据复制。 现代Linux网络堆栈可以通过利用商品Linux中所有常用的功能来实现每核42Gbps的吞吐量，例如。分段和接收卸载、巨型帧和分组引导。 虽然此吞吐量是针对单个长流的最佳情况，但主要开销在各种各样的Linux操作系统中是一致的-从内核缓冲区到应用程序缓冲区的数据复制（例如，，>单个长流的总CPU周期的50%）。这是在夏普与先前关于短流和/或低带宽链路的研究相反，其中协议处理被示出为主要瓶颈。我们还观察到接收端的数据包处理比发送端更早成为瓶颈。66∼∼影响。来自Linux网络社区的新兴零拷贝机制[11，12]可能会减轻数据拷贝开销，并且可能很快允许Linux网络堆栈使用单个核心处理多达100Gbps的数据。集成其他硬件卸载，如I/OAT [37]，可以透明地减轻数据复制开销，也可以提高性能。不提供零拷贝接口的传输协议[3，43]和用户空间网络栈[21，27，30]的硬件卸载可以提高微基准的吞吐量，但当集成到端到端系统中时，需要额外的机制来实现CPU效率。带宽延迟积（BDP）和缓存大小之间的差距减少导致次优吞吐量。 现代CPU支持直接缓存访问（DCA）（例如，IntelDDIO [25]）允许Intel将数据包直接DMA到L3缓存中，减少数据复制开销;鉴于其承诺，DDIO在大多数系统中默认启用。 虽然DDIO有望提高数据复制期间的性能，但令人惊讶的是，我们观察到即使对于单个流，它也会遭受高缓存未命中率（49%），从而提供有限的性能增益。我们的调查显示，这是相当微妙的原因：主机处理成为一个瓶颈，增加主机延迟的结果，结合增加接入链路带宽，BDP值增加。这种增长超过了L3缓存大小的增长-数据从NIC DMA到缓存，对于较大的BDP值，在应用程序执行缓存数据的数据复制之前，缓存会被快速覆盖因此，我们观察到每个核心的吞吐量下降了24%影响。我们需要更好地协调竞争连接之间的主机资源，以最大限度地减少主机上的延迟，并最大限度地减少数据复制期间的缓存未命中率。此外，窗口大小调整不仅要考虑延迟和吞吐量等传统指标，还要考虑L3大小。主机资源共享被认为是有害的。我们观察到，由于多个流共享主机资源的不良影响，不同流量模式（单流、一对一、incast、outcast和all-to-all）的每核吞吐量差异高达66%例如，同一NUMA节点上的多个流（因此，共享同一L3缓存）使缓存性能更差-在第一流的应用程序可以执行数据复制之前，由NIC DMA到缓存中的一个流的数据被NIC DMA到其他流的数据污染。多个流共享主机资源还导致到达NIC的分组属于不同的流;这又导致分组处理开销变得更糟，因为现有的优化（例如，使用通用接收卸载来合并分组）失去了聚集更大数量的分组的机会。这增加了每个字节的处理开销，并最终增加了调度开销。影响。 在互联网和早期的数据中心网络中，性能瓶颈是在网络核心中;因此，多个流“共享”主机资源并不具有性能影响。然而，对于高带宽网络，情况不再如此-如果目标是设计CPU高效的网络堆栈，则必须仔细编排主机资源，以最大限度地减少活动流之间的争用最近的接收器驱动的传输协议[18，35]可以被扩展以减少同时调度的流的数量，潜在地为未来的网络栈实现高CPU效率需要重新访问主机分层和数据包处理管道。 我们观察到多达43%的减少吞吐量-每核心相比，单流的情况下，应用程序生成的长流共享CPU核心与那些生成短流。这是由于增加的调度开销，也是由于短流处理的高CPU开销此外，短流和长流遭受非常不同的性能校验-前者具有高的分组处理开销，而后者具有高的数据复制开销;然而，今天的网络栈使用相同的分组处理流水线，而与最后，我们观察到，当生成长流的应用程序运行在与NIC不在同一NUMA域中的CPU核心上时，每核心吞吐量会额外下降20%（由于额外的数据复制开销）。影响。独立于网络层的CPU处理器的设计有利于两层的独立发展;然而，随着性能瓶颈转移到主机，我们需要重新考虑这种分离。例如，应用感知CPU调度（例如，调度在NIC本地NUMA节点上生成长流的应用，调度在单独的CPU核上的长流提高CPU效率。我们还应该重新考虑主机数据包处理流水线-与今天的设计不同我们的研究1不仅证实了许多令人兴奋的正在进行的活动，在系统，网络和架构社区设计CPU高效的主机网络堆栈，但也突出了几个跨学科的研究途径，在设计未来的操作系统，网络协议和网络硬件。我们在第4节中讨论它们在深入研究之前，我们概述了我们研究的几个警告。首先，我们的研究使用一个特定的主机网络堆栈（Linux内核）运行在一个特定的主机硬件上。虽然我们专注于识别趋势和绘制一般原则，而不是单个数据点，但主机网络堆栈和硬件的其他组合可能会表现出不同的性能特征。其次，我们的研究重点是CPU利用率和吞吐量;主机网络堆栈延迟是另一个重要的指标，但需要探索端到端系统中的许多其他瓶颈（例如，网络拓扑、交换机、拥塞等）;建立主机网络栈中的等待时间瓶颈及其对端到端等待时间的贡献的研究仍然是重要的且相对较少探索的领域。第三，内核网络堆栈发展迅速;我们的任何形式的研究都必须确定一个版本，以确保结果和观察结果的一致性;然而，我们的初步探索[7]表明，最新的Linux内核表现出与我们的结果非常相似的性能。最后，我们的目标不是对未来网络栈的发展（内核、用户空间、硬件）采取立场，而是获得更深入的理解一个高度成熟和广泛部署的网络堆栈。1所有的Linux插装代码和脚本，以及所有的文档都可以在http s：//githu b 上 找 到 。com m/Terabit-Ethernet/Terabit-network-stack-profiling.····67发送者App写套接字TCP/IP状态NetfilterXPS排队规定GSO驱动程序TX接收器App读出插座TCP/IP StateNetfilterRPS/RFSGRORX NAPIIRQ处置器用户空间内核空间应用程序和IRQ上下文之间的临界区中断读数据路径写数据路径物理传输合并/拆分套接字队列DRAM循环缓冲区硬件图1：Linux网络堆栈中的TCP和接收端数据路径描述见§2.1。表1：CPU使用分类。组件映射到层中，如图所示。1.2预赛Linux网络堆栈将许多组件紧密集成到端到端管道中。我们从回顾这些组件开始本节（§2.1）。我们还讨论了常用的优化，以及商品化Linux支持的相应硬件卸载。更详细的描述见[7]。然后，我们总结了我们研究中使用的方法（§2.2）。2.1端到端数据路径Linux 网络堆栈在发送端（应用程序到NIC ）和接收端（NIC到应用程序）的数据路径略有不同，如图所示1. 我们分别描述它们发送方 当发送端应用程序执行一个写系统调用时，内核会缓存套接字缓冲区（skb）。对于skb引用的数据，内核随后执行从用户空间缓冲区到内核缓冲区的数据复制然后由TCP/IP层处理skb 当准备好传输时（例如，拥塞控制窗口/速率限制允许），数据由网络子系统处理;这里，在其它处理步骤中，通过通用分段卸载（GSO）将skb分段成最大传输单元（MTU）大小的块，并在NIC驱动器Tx队列中排队。大多数商用TCP还支持数据包分段的硬件卸载，称为TCP分段卸载（TSO）;更多详情请参见[7]。最后，驱动程序处理Tx队列，为NIC创建必要的映射，以便从skb引用的内核缓冲区DMA数据重要的是，在今天的Linux网络堆栈中，几乎所有的发送端处理接收器侧。NIC有多个Rx队列和一个按Rx队列的页面池，DMA内存从该页面池中分配（由内核分页器支持）。NIC还具有可配置数量的Rx描述符，每个描述符都包含一个存储器地址，NIC可用于DMA接收到的帧。每个描述符都与一个MTU大小的帧的足够内存相关联。在接收到新帧时，NIC使用Rx描述符之一，并将帧DMA到与描述符相关联的内核存储器通常，NIC将帧DMA到DRAM;然而，现代CPU支持直接缓存访问（DCA）（例如，使用Intel的Data Direct I/O技术（DDIO）[25]），允许NIC将帧直接DMA到L3缓存。DCA使应用程序能够避免访问DRAM来访问数据。NIC以异步方式生成一个IRQ请求，通知驱动程序要处理的新数据处理IRQ的CPU内核由NIC使用其中一种硬件转向机制选择;参见表2以获得摘要，以及[7]以获得接收端流转向技术如何工作的详细信息。在接收到IRQ时，驱动程序触发NAPI轮询[17]，这为纯粹基于中断的网络层处理提供了一种替代方案-系统忙轮询进入的帧直到接收到一定数量的帧或者定时器到期2.这减少了IRQ的数量，特别是对于传入数据速率很高的高速网络在忙轮询时，驱动程序为每帧分配一个skb，并在skb和内核存储器中的帧已被DMA。如果NIC已写入足够的数据来消耗所有Rx描述符，驱动程序使用页面池分配更多的DMA内存并创建新的描述符。然后，网络子系统尝试通过使用通用接收卸载（GRO）或其对应的硬件卸载大接收卸载（LRO）合并skb来减少skb的数量;参见[7]中的接下来，TCP/IP处理被安排在使用系统中启用的流操纵机制的CPU内核（参见表2）。重要的是，启用aRFS后，所有处理（2这些NAPI参数可以通过net.core.netdev_budget和net.core.netdev_budget_usecs内核参数进行调优， 在我们的Linux发行版中，这些参数默认设置为300和2ms。应用•调度•数据拷贝套接字接口•SKB管理•锁定/解锁•内存分配/释放TCP/IP协议栈•TCP/IP处理网络子系统•Netdevice子系统•SKB管理设备驱动程序•内存分配/释放•调度组件描述数据拷贝从用户空间到内核空间，反之亦然。TCP/IP所有的数据包处理都在TCP/IP层。网络设备子系统Netdevice和NIC驱动程序操作 （ 例 如 NAPI 轮 询 、GSO/GRO、qdisc等）。SKB管理构建、拆分和释放skb的函数。Memoryde-/allocSKB解/分配和页面相关操作。锁定/解锁锁定相关操作（例如自旋锁）。调度线程间的调度/上下文切换别人所有其他功能（例如：IRQ处理）。68−∼∼机制描述接收分组引导（RPS）使用4元组散列进行核心选择。接收流转向（RFS）找到应用程序运行的核心。接收侧转向（RSS）RPS支持的硬件版本加速RFS（aRFS）Linux支持的RFS硬件版本表2：接收器侧流转向技术。IRQ处理程序、TCP/IP和应用程序）在同一CPU上执行（a）单身（b）一对一（c）被安置（d）被抛弃（e）所有人对所有人核心一旦被调度，TCP/IP层处理就被执行，并且所有有序的skb都被附加到套接字最后，应用程序线程将套接字接收队列中的skb中的有效负载复制到用户空间缓冲区。请注意，在发送端和接收端，数据包有效载荷的数据复制仅执行一次（当数据在用户空间和内核空间之间传输时）。内核中的所有其他操作都是使用skb上的元数据和指针操作来执行的，并且不需要数据复制。2.2衡量方法在本小节中，我们简要描述了我们的测试台设置，实验场景和测量方法。试验台设置。为了确保瓶颈在网络堆栈上，我们设置了一个测试床，其中两台服务器通过100 Gbps链路直接连接（没有任何中间交换机）。我们的两台服务器都有一个4插槽的NUMA支持的英特尔至强金牌6128 3. 4GHz CPU，每个插槽6个内核，32 KB/1 MB/20 MB L1/L2/L3缓存，256 GB RAM，以及连接到其中一个插槽的100 Gbps Mellanox ConnectX-5 Ex两台服务器都运行Ubuntu 16。04与Linux内核5. 第四章43.除非另有说 明 ， 否 则 我 们 在 实 验 中 启 用 DDIO ， 并 禁 用 超 线 程 和IOMMU实验场景。 我们使用五种标准流量模式研究网络堆栈性能（图1）。2）-单流、一对一、incast、outcast和所有对所有使用的工作负载，包括长流、短流，甚至是长流和短流的混合。对于生成长流，我们使用标准的网络基准测试工具iPerf[14]，它将流从发送者传输到接收者;对于生成短流，我们使用支持乒乓风格RPC工作负载的netperf [22]这两种工具都执行最小的应用程序级处理，这使我们能够专注于网络堆栈中的性能瓶颈（而不是由于应用程序和网络堆栈之间的复杂交互而产生的瓶颈）;如果应用程序执行额外的处理，我们的许多结果可能具有不同的特征。我们还研究了网络拥塞的影响，DDIO的影响和IOMMU的影响我们使用Linux对于每个场景，我们都将内联描述设置业绩指标。 我们测量所有核心的总吞吐量、总CPU利用率（使用sysstat [19]，其中包括图2：我们研究中使用的交通模式。(a)从一个发送器核心到一个接收器核心的单一流。（b）从每个发送器核到唯一的接收器核的一个流。（c）来自每个发送器核的一个流，全部到单个接收器核。（d）从单个发送器核到每个接收器核的一个流。（e）每对发送器和接收器核之间的一个流。3Linux网络堆栈开销我们现在评估各种场景的Linux网络堆栈开销，并对观察到的性能提出详细的见解3.1单流我们从两个服务器之间的单个流开始，每个服务器在NIC本地NUMA节点的CPU核心上运行一个应用程序我们发现，不像互联网和早期的数据中心网络的吞吐量瓶颈主要是在网络的核心（因为一个单一的CPU就足以饱和的访问链路带宽），高带宽网络引入新的主机瓶颈，即使是一个简单的情况下，一个单一的流。在深入研究之前，我们对单流情况的实验配置做一个说明。 当aRFS被禁用时，由于默认RSS机制使用4元组的散列来确定IRQ处理的核心，因此很难获得稳定和可重复的测量结果（第2.1节）。由于4元组可以跨运行改变，因此执行IRQ处理的核心可以是：（1）应用核心;（2）相同NUMA节点上的核心;或者（3）不同NUMA节点上的核心这三种情况下的表现各不相同，导致了非确定性。为了确保确定性测量，当aRFS被禁用时，我们对最坏情况的场景（情况3）进行建模：我们显式地将IRQ映射到与应用程序核心不同的NUMA节点上的核心。有关其他可能的IRQ映射场景的更详细分析，请参见[7]。一个核心已经不够了。 对于10个 40Gbps的接入链路带宽，单个线程能够使网络带宽饱和。然而，这不再是高带宽网络的情况下：如图所示3（a），即使启用了所有优化，Linux网络堆栈也能实现42Gbps的每核心吞吐量3。巨型帧4和TSO/GRO都减少了每字节的处理开销，因为它们允许每个skb带来更大的有效载荷（分别高达9000 B和64 KB）。即使启用了GRO，巨型帧也很有用，因为要合并的skb数量随着MTU大小的增加而减少，从而减少了软件中数据包聚合的处理开销。 aRFS和DCA通常内核和应用程序处理）以及每核吞吐量比率瓶颈（发送方或接收方）的总吞吐量和总CPU利用率。为了执行CPU分析，我们使用标准的我们采用占CPU利用率95%的顶级函数。通过检查内核源代码，我们将这些函数分为8类，如表1所示。3通过仔细调整NIC Rx描述符和TCP Rx缓冲区大小，我们观察到每核最大吞吐量高达55Gbps（见图3）。3（e）），或使用LRO而不是GRO（见[7]）。然而，这种参数调整对硬件设置非常敏感，因此我们将它们保留为所有其他实验的默认值此外，LRO的当前实现在某些情况下会导致问题，因为它可能会丢弃重要的报头数据，因此在现实世界中经常被禁用[10]。因此，我们使用GRO作为我们的实验的其余部分的接收卸载机制4使用更大的MTU大小（9000字节），而不是正常的（1500字节）。AppAppAppAppAppAppAppAppAppAppAppAppApp应用应用程AppAppAppAppAppAppAppAppAppAppAppAppAppAppAppAppAppAppAppAppApp69×6050403020100所有选项6050403020100不包括TSO/GRO不带Jumbo3002502001501005006050403020100无选项+TSO/GRO+巨型+aRFS(a) 每核心吞吐量（Gbps）(b) CPU利用率（%）(c) CPU故障807060504030201001282565121024204840968192160140120100806040200300025002000150010005000100200400800160032006400 12800(d) 接收机CPU故障尔斯则(e) 缓存未命中率（%）TCP Rx缓冲器大小（KB）(f) 从NAPI到开始数据拷贝的图3：单流情况下的Linux网络堆栈性能（a）每列显示了针对不同优化组合实现的每核心吞吐量。在每一列中，优化以增量方式启用，每个彩色条显示启用相应优化的增量影响。（b）由于所有优化都是递增启用的，因此CPU和Receiver的总CPU利用率。与启用的优化无关，接收端CPU是瓶颈。（c，d）在启用所有优化的情况下，数据复制是CPU周期的主要消耗者（e）NIC环形缓冲区大小的增加和TCP Rx缓冲区大小的增加导致高速缓存未命中率增加和吞吐量降低（f）从NAPI到数据复制开始的网络栈处理延迟描述见§3.1通过使NIC本地NUMA节点核心上的应用程序能够直接从L3缓存执行数据复制，接收端CPU是瓶颈。 图图3（b）示出了发送方和接收方侧的总体CPU利用率。与启用的优化无关，接收端CPU是瓶颈。有两个主要的开销造成了发送方和接收方CPU利用率之间的差距：（1）数据复制和（2）skb分配。首先，当aRFS被禁用时，帧被DMA到接收器处的远程NUMA这在发送端不是问题，因为本地L3高速缓存与应用程序发送缓冲区数据是热的。启用aRFS解决了这个问题，与未启用优化的情况相比，接收方的CPU利用率降低了2（图3（b）中最右侧的条）;但是，接收方的CPU利用率仍然高于发送方。其次，当TSO被启用时，发送方能够分配大尺寸的skb。然而，接收器在设备驱动器处分配MTU大小的skb，然后在GRO层处合并skb。因此，接收方承担了更高的skb分配开销CPU周期在哪里 图图3（c）和3（d）显示了每个优化组合的发送方和接收方的CPU使用率明细在没有任何优化的情况下，CPU开销主要来自TCP/IP处理，因为每个skb处理开销很高（这里，skb大小在两端都是1500 B5）。当aRFS被禁用时，由于应用程序上下文线程（recv系统调用）和中断上下文线程（softirq）试图访问同一个套接字实例，导致套接字争用，因此接收端的锁开销很高4. Linux内核17以后，默认情况下启用GSO。我们修改了内核，在“无优化”实验中禁用GSO，这些数据包处理开销通过几种优化来减轻：TSO允许在发送端使用大尺寸的skb，减少TCP/IP处理和Netdevice子系统开销，因为分段被卸载到NIC（图11）。3（c））。在接收器侧，GRO通过减少传递到上层的skb的数量来减少CPU使用，因此TCP/IP处理和锁定/解锁开销显著减少，代价是增加了执行GRO的网络设备子系统的开销（图1）。3（d））。如上所述，通过启用巨型帧，可以将该GRO成本降低66%这些减少的数据包处理开销导致吞吐量的提高，并且主要开销现在转移到数据复制上，当GRO和Jumbo帧被启用时，数据复制占用了接收端总CPU利用率的近49%一旦启用了aRFS，应用程序上下文线程和IRQ上下文线程在接收器处的协同定位将导致改进的缓存和NUMA局部性。这种做法有两方面的影响(1) 由于应用程序线程与NIC在同一NUMA节点上运行，因此它现在可以直接从L3缓存（由NIC通过DCA进行DMA）执行数据复制。这减少了每字节的数据复制开销，从而提高了每核吞吐量。(2) 在软中断线程中分配SKB，并在应用上下文线程中释放SKB（一旦完成数据复制由于两共置，存储器重新分配开销减少。这是因为对本地NUMA内存的页释放操作比对远程NUMA内存的页释放操作要便宜得多即使是单个流也会经历高缓存未命中。虽然aRFS允许应用程序从本地L3缓存执行数据复制这是令人惊讶的，因为对于单个流，无可选TSO/GROJumboaRFS总Thpt接收机CPU利用率总Thpt0.60.50.40.30.20.10+TSO/GRO+Jumbo+aRFS0.60.50.40.30.20.10+TSO/GRO+Jumbo+aRFS吞吐量缓存未命中率3200默认32OOKB默认6400128OOKB64OOKB128OOKB不我Avg. LatencyTail（99p）延迟托塔Mis s从NAPI到应用程序的延迟（us）70∼∼L3缓存容量。为了进一步研究这一点，我们改变了各种参数，以了解它们对缓存未命中率的影响。在我们的实验中，改变最大TCP接收窗口大小和NIC Rx描述符的数量揭示了一个有趣的趋势。图3（e）示出了吞吐量和L3高速缓存未命中率随NIC Rx描述符的数量变化和TCP Rx缓冲区大小变化的变化。我们观察到，随着NIC Rx描述符数量或TCP缓冲区大小的增加，L3缓存未命中6050403020100NIC-本地NUMA120100806040200增加，并且相应地，吞吐量降低。我们已经发现了这种现象的两个原因：（1）BDP值大于L3缓存容量;（2）次优缓存利用率。为了理解第一个，考虑一个极端情况，即TCP Rx缓冲区大小很大。在这种情况下，TCP将保持BDP价值的数据在飞行中，其中BDP被定义为接入链路带宽和延迟（网络和主机延迟）的乘积事实证明，大型TCP缓冲区可能会导致主机延迟显著增加，特别是除了IRQ上下文和应用程序线程的调度延迟外，我们还观察到每个数据包都观察到前一个数据包后面的我们通过记录时间戳来测量帧接收和数据复制开始之间的延迟当一个skb的NAPI处理发生时，以及当它的数据复制开始时的时间戳，并测量the two.图3（f）示出了在不同TCP Rx缓冲区大小的情况下观察到的平均延迟和第99百分位延迟。可以看出，随着TCP Rx缓冲区大小超过1600KB，考虑到DCA缓存大小有限7，延迟的增加会产生显著影响：由于TCP缓冲区和BDP值很大，NIC始终有数据要DMA;因此，由于NIC DMA的数据不会立即复制到用户空间缓冲区，因此当NIC执行后续DMA时，它会从缓存中被驱逐（如果NIC用完Rx描述符，驱动程序会在NAPI轮询期间重新配置NIC Rx描述符结果，缓存未命中增加，吞吐量降低。当TCP缓冲区大小足够大时，这个问题仍然存在，与NIC环形缓冲区大小无关。要理解第二个原因，请考虑另一个极端，即TCP缓冲区大小很小，但NIC环形缓冲区大小很大。我们认为这种情况下的缓存未命中可能是由于不完美的缓存替换策略和/或缓存的复杂寻址，导致缓存利用率不佳;最近的工作已经观察到类似的当存在大量NIC Rx描述符时，存在相应地更大数量的存储器地址可用于NIC以DMA数据。因此，即使传输中的数据的总量小于高速缓存容量，DCA写入驱逐一些先前写入的数据的可能性也随着NIC Rx描述符的数量而增加这限制了高速缓存容量的有效利用，导致高速缓存未命中率高和每核心吞吐量低。在这两个极端之间，这两个因素都有助于图1中观察到的性能3（e）. 事实上，在我们的设置中，DCA缓存容量为1.3MB，因此TCP缓冲区大小为3200KB或更少512个NIC Rx描述符（512× 9000字节，约4MB）6内核对TCP Rx套接字缓冲区大小使用自动调优机制，目标是最大化吞吐量。在本实验中，我们通过指定Rx缓冲区大小来覆盖默认的7在我们的设置中，DCA只能使用L3缓存容量的18%（103 MB）图4：NIC远程NUMA节点上单个流的Linux网络堆栈性能 与NIC本地NUMA节点情况相比，每个核心的单流吞吐量下降了20%。55Gpbs的最佳单核吞吐量。这里有一个有趣的观察结果是，今天Linux内核网络堆栈中使用的默认自动调优机制没有意识到DCA效应，最终会超过最佳操作点。DCA仅限于NIC本地NUMA节点。到目前为止，在我们的分析中，应用程序运行在NIC本地NUMA节点的CPU核心上。现在我们将研究在用于相同单流实验的NIC远程NUMA节点。图4显示了相对于NIC本地情况（在两种情况下都启用了所有优化当应用程序在NIC远程NUMA节点上运行时，我们看到L3缓存未命中率显著增加，每核吞吐量下降20%由于启用了aRFS，NIC DMA将帧发送到目标CPU但是，由于目标CPU内核位于NIC远程NUMA节点上，因此DCA无法将DMA帧数据推送到相应的L3缓存中[25]。因此，缓存未命中增加，每核吞吐量下降。3.2通过一对一增加竞争我们现在评估对网络带宽具有较高争用的Linux网络堆栈。在这里，每个发送方核向一个唯一的接收方核发送流，并且我们将核/流的数量从1增加到24。虽然每个流仍然具有用于其自身的整个主机核心，但是与单流情况相比，该场景引入了两个新的挑战：（1）网络带宽随着使用多个核心而变得饱和;以及（2）流在NIC本地和NIC远程NUMA节点上运行（我们的服务器在每个NUMA节点上具有6个核心）。与§3.1类似，为了在aRFS禁用时获得确定性测量，我们将各个应用程序的IRQ显式映射到不同NUMA节点上的唯一核心。随着流数量的增加，主机优化变得不那么有效 图图5（a）示出， 随着流的 数量增加 ，每个核 的吞吐量减 少64%（即，15Gbps，24个流），尽管每个核心只处理单个流。这是因为所有优化的有效性降低特别是，与单流情况相比，aRFS的有效性在24流情况下降低了75%;这是由于NIC本地NUMA节点核心（所有核心共享L3缓存）的数据拷贝的L3缓存局部性降低，也是由于在NIC远程NUMA节点上运行的某些流（无法利用DCA，请参见§3.1，图4）。GRO的有效性也降低了：由于接收端的数据包现在是跨流交织的，因此聚合的机会更少;这在所有对所有的情况下将变得更加突出，并在§3.5中进行了更深入的讨论。每核接收器吞吐量：缓存未命中率每核心吞吐量（Gbps）缓存未命中率（%）71无可选TSO/GROJumboARFs总Thpt∼5010040 8030 600.60.50.40.30.60.50.40.3204010200 01 8 16 24流量数量0.20.100.20.10(a) 每核心吞吐量（Gbps）(b) CPU故障(c) 接收机CPU故障图5：一对一流量模式的Linux网络堆栈性能（a）每一列显示了不同数量的流所实现的每核心吞吐量。在8个流时，网络饱和，然而，每核吞吐量随着流的增加而降低。（b、c）在启用所有优化的情况下，随着流的数量增加，花费在数据复制中的CPU周期的分数减少。在接收端，网络饱和导致内存管理开销降低（由于更好的页面回收）和调度开销增加（由于频繁的空闲）。 对于x = 1、8、16和24的情况，总的接收器侧CPU利用率为1、3。七十五，五。21和6。分别为58个核心。描述见§3.260504030201001 8流量数量605040302010016 240.60.50.40.30.20.10454035301 8 1624流量数量100908070605040(a) 每核心吞吐量（Gbps）(b) 接收机CPU故障(c) L3缓存未命中率（%）图6：Incast流量模式的Linux网络堆栈性能。(a)每列显示不同数量的流的每核吞吐量（在所有情况下，接收器核都是经过校验的）。总吞吐量随着流数量的增加而减少（b）在启用所有优化的情况下，每个组件所使用的CPU周期的分数不会随着流的数量而显著改变见[7]发送端CPU故障。（c）接收器侧高速缓存未命中率随着流的数量而增加，从而导致更高的每字节数据复制开销和降低的每核吞吐量。描述见§3.3处理开销随网络饱和度而变化。如图5（a）所示，在8个流处，网络链路成为瓶颈，并且吞吐量最终在所有核之间公平地共享。图5（c）显示了瓶颈在这种情况下的转移：调度开销增加，内存管理开销减少。直觉上，当网络饱和时，接收器核心在某些时间开始变得空闲-线程在等待数据时重复地进入睡眠，并在新数据到达时唤醒;这导致上下文切换和调度开销增加。随着流量的增加，这种影响变得越来越突出（图1）。5（b），Fig.5（c）），因为每个核的CPU利用率降低。为了理解内存分配/释放开销的减少，我们观察到内核页面分配器维护每个核心的分页，其中包括一定数量的空闲页面。在分配请求时，如果可用，可以直接从分页表中获取页面;否则需要访问全局自由列表（这是一个更昂贵的操作）。当多个流共享接入链路带宽时，每个核心服务于相对于单个流情况的较少的业务量 这允许使用过的页面在变空之前被回收回分页存储器，从而减少内存分配开销（图1）。5（c））。3.3通过Incast增加接收方争用我们现在使用Incast流量模式在接收方核心创建额外的争用，将流的数量从1变化到24（每个流在发送方使用一个唯一的核心与前面的场景相比，此场景会引起对（1）CPU资源的更高争用，作为L3缓存和（2）应用程序线程之间的CPU调度我们将讨论这些变化如何影响网络处理开销。每字节数据复制开销随着每核流的增加而增加图6（a）显示，每个核的吞吐量随着流数量的增加而降低，与单流情况相比，观察到8个流的下降多达19%。图6（b）显示CPU故障不会随着流数量的增加而显著变化，这意味着CPU开销没有明显的变化。图6（c）提供了对每核吞吐量下降的根本原因的一些直观认识。随着每个核的流的数量在接收器侧增加，用于不同流的应用竞争相同的L3高速缓存空间，导致高速缓存未命中率增加（随着流的数量从1变为8，未命中率从48%增加到78%）。除此之外，这会导致每字节数据复制开销增加和每核心吞吐量减少。如图如图6（c）所示，L3高速缓存未命中率随着流的增加而增加，这与每核吞吐量的下降很好地相关。TCP的发送端驱动特性排除了接收端调度。上面观察到的更高的缓存争用是同一核心上的多个活动流的结果。虽然TCP可以使用仔细的流调度来潜在地减少这种争用，但是接收器侧的问题是根本性的：TCP协议的发送器驱动的性质排除了接收器控制每个核心的活动流的数量，从而导致不可避免的CPU效率低下。我们相信接收器驱动的协议[18，35]可以为接收器提供这种控制，从而实现CPU高效的传输设计。1个月8条评论16架飞机24辆摩托车1个月8条评论16架飞机24辆摩托车无可选TSO/GROJumboaRFS总Thpt1个月8条评论16架飞机24辆摩托车每核心吞吐量（Gbps）每核接收器吞吐量：缓存未命中率每核心吞吐量（Gbps）总吞吐量（Gbps）总吞吐量（Gbps）CPU周期CPU周期每核心吞吐量（Gbps）CPU周期缓存未命中率（%）72×∼∼∼∼×××∼14012010080604020018 1624#现在，1401201008060402000.60.50.40.30.20.10600500400300200100060504030201001 8 16 24流量数量(a) 每核心吞吐量（Gbps）(b) CPU故障(c) CPU利用率（%）图7：针对Outcast流量模式的Linux网络堆栈性能。(a)每一列显示针对不同数量的流实现的每发送器核的吞吐量，即使用单个发送器核可持续的最大吞吐量（我们在这里忽略接收器核利用率）。每个发送器核心的吞吐量从1增加到8个流，然后随着流数量的增加而减少。（b）在启用所有优化的情况下，随着流的数量从1增加到8，数据复制开销增加，但是当流的数量进一步增加时，数据复制开销没有太大变化接收端CPU故障参考[7]（c）对于1个流，发送方CPU未得到充分利用。随着流的数量从8增加到24，发送端缓存未命中率略有增加，增加了每字节数据复制开销，并且每核吞吐量相应降低。描