业界首个NIC中PCIe性能测试基准程序公布！

年来，在可编程NIC的发展和可用性的刺激下，终端主机已日益成为核心网络功能（如负载平衡，拥塞控制和特定于应用程序的网络卸载）的执行点。但是，在可编程NIC上实现自定义设计并不容易：许多潜在的瓶颈会影响性能。本文着重于与主机体系结构和设备驱动程序进行交互时，PCIe（现代服务器中的实际I / O互连）的性能含义。论文首次提供了一个理论模型和方法，pcie-bench，来理解和研究PCIe协议的内在瓶颈。pcie-bench有点类似于以太网不同帧长时计算出的实际网络速率一样，结合实际测试结果，总结了不同情况下PCIe能够提供的真实带宽。论文还探索了新的PCIe和主机体系结构特性(如DDIO和IOMMUs)的影响。具体来说是证明了PCIe与DDIO高速缓存的集成工作良好，但同时也说明了Intel IOMMUs和NUMA在需要高DMA速率时可能产生的显著影响(有时是不受欢迎的)。 按照惯例，我们推荐的文章一般都有开源源码，开源地址如下：https://www.pcie-bench.org，https://github.com/pcie-bench。感兴趣的可以学习一下。下图就是笔者运行其中的python程序跑出来的40G以太网口不同帧长下实际能够达到的速率。

近年来，在可编程NIC的发展和可用性的推动下，终端主机逐渐成为核心网络功能(如负载平衡、拥塞控制和特定应用网络卸载)的实施点。然而，在可编程NIC上实现定制设计并不容易:许多潜在的瓶颈会影响性能。

本文重点讨论PCIe的性能影响，即在现代服务器中，与主机架构和设备驱动程序交互时，实际上的I/O互连。我们为PCIe和pcie-bench提供了一个理论模型，这是一个开源套件，允许开发人员获得对PCIe基板的准确和深入的理解。使用pcie-bench，我们描述了现代服务器中PCIe子系统的特征。我们强调了PCIe实现中令人惊讶的差异，评估了PCIe特性(如IOMMUs)的不良影响，并展示了以40Gb/s及更高速度运行时普通网卡的实际限制。此外，通过pcie-bench，我们获得了一些见解，这些见解为面向商业和研究的网卡以及DMA引擎的软件和未来的硬件架构提供了指导

CCS CONCEPTS

Networks → Network adapters; Network servers; • Hardware→Networking hardware;Buses and high-speed links

关键词

PCIe，可重构硬件，操作系统

介绍

终端主机参与网络功能实施的想法已经在企业和数据中心网络中得到广泛探讨[6，7，25，49，56，58]。此外，可编程网卡市场的颠覆性引入，以及Xeon和FPGA平台在数据中心的部署[15]，推动了对新的优化解决方案的需求，这些解决方案将软件功能和硬件网卡加速相结合，以提高终端主机的网络性能[53]、灵活性[16]或者两者都得到提升[29]。一些努力试图利用终端主机硬件的可编程性来提高数据中心的可扩展性[12，13]或特定的网络功能，如负载平衡、应用级服务质量和拥塞控制[1]。

在本文中，我们展示了PCIe，以及它与主机架构和设备驱动程序的交互，它可以显著影响网络应用程序的性能。过去的研究主要是在特定应用的背景下考虑这种影响，例如Remote DMA (RDMA) [24]，GPU加速的数据包处理[17]，以及优化的键值存储(KVS)应用[31，32，34]。相比之下，我们认为需要一种更通用的方法来研究和描述PCIe，因为PCIe已经变得不可或缺，如今PCIe不仅要实现专门的、高性能的网络功能，还要实现存储适配器和定制的加速器卡，例如用于机器学习[23]。正是在这种背景下，我们为PCIe引入了一个理论模型（第3节），设计了一种方法来描述真实系统中的PCIe(第4节))，描述了它的实现(第5节)，并给出了使用我们的方法而得到的结果(第6节)。这让我们可以得出几个关于PCIe目前运作方式的具体结论，以及这对操作系统和应用程序设计的影响(第7节)。例如，我们演示了PCIe NUMA设备和IOMMUs如何对应用程序性能产生负面性影响。

本文的贡献在于：

• 我们介绍了一个PCIe的模型。该模型为各种PCIe配置的预期吞吐量范围提供了底线。它还允许在遍历设备和设备驱动程序交互的设计方案时，快速评估其性能影响，例如在实现自定义网卡功能时。
• 我们介绍了一种方法，pcie-bench:一种微基准组合，它可以系统地测量设备的DMA引擎以及更重要的PCIe root complex的性能。
• 我们描述了基于商用PCIe外围设备的pcie-bench的两种实现方式:来自Netronome的商用可编程NIC和最新的NetFPGA板。这些实现方式是开源的，以实现我们的结果的可再现性，并使其他从业者能够应用于其他系统和架构。
• 我们首次公开披露了几代传统主机系统的PCIe性能的详细测量结果；这使我们能够跟踪PCIe根复合体实现的演变，并指出了甚至来自同一个供应商的不同实现之间的一些令人惊讶的差异。
• 我们讨论了从pcie-bench的一些实际应用中学到的经验。从最初需要表征、调试和改进实施，直到帮助和评估由可编程NIC所支持的定制解决方案的不断增长的研究领域。此外，这些结果也直接适用于越来越多的其他高性能产品，如专用加速卡。

目的

传统上，商用系统(如PCIe)中的I/O互连没有得到广泛研究，部分原因是它们已经有效工作了很多年。只有当我们的I/O设备接近(并超过)PCIe提供的功能时，例如双端口40Gb/s网络适配器，我们才能看到大量考虑到PCIe限制的软硬件协同设计[16，29，30]。除此之外，还提出了许多新的软件框架来避免传统网络堆栈的开销[3，8，46，54]。

不幸的是，有了40Gb/s和100Gb/s的NIC之后，PCIe即使与优化的软件堆栈相结合，也正在成为瓶颈。此外，具有严格延迟要求的现代网络应用可能会受到PCIe设备中的DMA引擎和PCIe终端主机设备所引入的延迟的影响。最后，PCIe在现代基于x86的服务器中的主机端设备中已经发生了巨大变化，替代服务器体系结构也正在出现。我们现在更详细地看以下这些方面。

PCIe对网络应用吞吐量的影响。PCIe Gen 3 x8接口通常由40Gb/s网卡使用，物理层的吞吐量为62.96 Gb/s。然而，PCIe协议开销将可用带宽减少到大约50 Gb/s，或明显更少，这将取决于PCIe的访问模式。图1显示了这种设备可实现的有效双向带宽(有效PCIe带宽)。锯齿图形是由PCIe协议的分组结构引起的，在该结构中，要传输的数据，例如网络包，被分解成具有它们自己PCIe级报头的较小的PCIe分组。

除了传输数据包本身，NIC还必须读取发送引擎和空闲描述符队列，写回接收(有时是发送)描述符并产生中断。设备驱动程序还必须读取和更新设备上的队列指针。所有这些交互都是消耗额外PCIe带宽的PCIe事务。如果我们模拟一个非常简单的NIC，它为每个数据包分配单独的描述符，并且驱动程序为每个数据包读取/写入队列指针，那么我们可以看到可实现的双向带宽(简单NIC)会急剧下降。对于大于512B的以太网帧，这种设备只能实现40 Gb/s的线路速率吞吐量。因此，大多数现代NIC(和驱动程序)都实现了许多优化，例如分批排列描述符、预取描述符、中断调节等。这些优化增加了NIC的复杂性，但达到了需要的吞吐量。图中的现代NIC（内核驱动程序)显示了这种适度优化的网卡/驱动程序组合在使用典型的Linux内核驱动程序时的吞吐量。现代软件框架，如DPDK [8]，能够在驱动程序层面进行进一步优化(不改变网卡硬件)。通过禁用中断和轮询主机存储器中的回写描述符(而不是设备寄存器)，PCIe事务的数量将进一步减少，并且可实现的带宽增加(现代NIC(DPDK驱动程序))。我们在第3节中详细介绍了这些模型是如何推导出来的。然而，图1显示，当设计定制卸载到可编程NIC时，开发人员和研究人员必须敏锐地意识到由设备和设备驱动程序引起的PCIe事务带来的开销。

PCIe对网络应用程序延迟的影响。我们使用了一个ExaNIC [11]来估计PCIe对网络应用程序所经历的终端主机延迟的影响。我们执行了一个环回测试来测量不同大小数据包的总网卡延迟(从应用程序到线路再到网络)。该测试将数据包写入驱动程序的缓冲区，并测量数据包开始写入PCIe和数据包返回之间的延迟。该测试使用内核旁路模式，因此不包括任何内核开销。我们还修改了ExaNIC固件，使用ExaNIC固件开发工具包来测量PCIe延迟的影响。

图2显示了测试结果。在ExaNIC，对于1500 B的数据包，PCIe子系统造成了77%的延迟，对于小数据包，延迟增加到90%以上。特别是，总体延迟完全在范围内，这已被证明对几个常见数据中心应用的性能有负面影响[63]。

网卡PCIe延迟的测量。图2显示，128B有效负载的往返延迟约为1000ns，PCIe占了其中约900ns。对于线路速率为40 Gb/s的以太网，每30ns左右需要接收和发送一个新的数据包。假设测得的PCIe延迟是对称的，这意味着网卡必须在每个方向处理至少30个并发的内存分配，以适应这种延迟，从而实现128 B数据包的线路速率。考虑到NIC还必须为描述符发布动态内存分配，所有NIC必须处理的动态内存分配数量甚至会更高。此外，正如我们在6.2中所展示的，一些系统引入了延迟的显著变化，NIC的DMA引擎也必须适应这种变化。这不仅在为可编程NIC编写优化软件时引入了显著的复杂性，而且还强加了设备驱动程序必须批量提供足够大的主机缓冲区以供网卡使用的限制。

PCIe根复合体正在进化。在基于x86的现代服务器中，PCIe根复合体近年来发展迅速。具体来说，连同内存控制器一起，它与CPU内核紧密集成，使得PCIe设备与CPU的高速缓存能更紧密地集成，例如Intel’s Data Direct I/O (DDIO) [20]。对于多时钟系统，这种集成还会导致PCIe设备的非统一内存访问(NUMA [28]):一些DMA请求可能针对PCIe设备所连接的本地内存，而其他请求则需要遍历CPU互连。最后，大多数现代系统都在PCIe设备和主机之间的数据路径中插入了一个IOMMU[22]。IOMMU对PCIe事务中存在的地址执行地址转换，并利用内部事务后备缓冲器(TLB)作为已转换地址的缓存。在TLB未命中时，IOMMU必须执行全页表遍历，这可能会延迟事务，从而增加延迟并影响吞吐量。这些最新技术不仅影响了PCIe事务的总延迟(和带宽)，而且还带来了变化，因为事务现在依赖于高速缓存的当前状态、IOMMU TLB和CPU互连的特性。此外，经过服务器市场多年相对单一的x86体系结构，围绕ARM64和Power处理器的设计已经得到主流部署。这些体系结构中的每一个都具有非常不同的I/O子系统的设备，并且大多数相关的细节都是不公开的，这使得研究人员很难描述和理解这些服务器体系结构之间的差异。

当需要将数据从硬件传输到软件时(反之亦然)，PCIe对吞吐量的影响，PCIe对整体网卡延迟的主要贡献，PCIe根复合体中新技术的引入，以及新服务器体系结构的主流部署都促使我们构建pcie-bench能够:更好、更详细、更系统地了解PCIe在商用系统中的实施，并帮助开发人员微调应用程序，以更有效地利用底层系统。

PCIe建模

作为pcie-bench的一部分，我们开发了PCIe规范的模型[47，57]。该模型允许我们:(1)根据规范，对照预期带宽，验证来自微基准的带宽测量结果，以及(2)模拟更复杂的设备/主机交互的影响，如图1所示的NIC模型。

PCIe使用基于点对点拓扑的高速串行互连，而点对点拓扑由端点之间的若干串行链路(或通道)组成。PCIe是一个有三层的协议:物理层、数据链路层和事务层。当数据链路层实现纠错、流量控制和确认时，事务层使用事务层数据包将用户应用数据或完成数据转换为PCIe事务。

目前大多数可用的40Gb/s的NIC都有一个8通道的PCIe Gen 3接口。每条通道使用128b/130b编码提供8 GT/s(每秒千兆事务数)，这导致物理层为8 × 7.87 Gb/s = 62.96 Gb/s。由于流量控制和确认消息，动态链接库增加了大约8-10%的开销，在TLP层留下了大约57.88 Gb/s的可用空间。对于每个事务，物理层添加2B帧，而动态链接库添加6B报头。

在传输层，标准定义了许多不同的TLP类型。就本文而言，相关的数据包类型有:存储器读(MRd)、存储器写(MWr)和带数据完成包(CplD)。TLP有一个公共头标、一个特定类型的头和一个可选的尾部摘要。公共报头包含了TLP类型和TLP长度等信息，大小为4B。MWr和MRd 的TLP的报头为12B长(假设64位寻址)，而对于CplD 的TLP则为8B。单个TLP中承载的最大数据量(最大有效负载大小)由对等方协商决定，而可选的4B摘要包含了端到端循环冗余校验(ECRC)。MPS的典型值为256或512。

PCIe 的MWr事务是简单的posted事务，大小为sz的DMA写所传输的字节数可以通过以下公式计算:

其中MW r_Hdr为24B (2B成帧、6B DLL报头、4B TLP报头和12B MWr报头)。相反，PCIe存储器读(MRd)，例如从主机读取数据的设备，需要两种TLP类型:MRd TLP和CplD TLP。发送MRd TLP以向对等方请求数据，然后对方通过一个或多个带数据完成包返回数据。因此，PCIe内存读取会消耗两个方向的带宽。一个读请求只能请求一定数量的数据(最大读请求大小，或MRRS)，由对等方协商决定。MRRS的典型值是512B。通过带数据完成包所返回的数据受MPS约束。

大小为sz的DMA读所消耗的字节数是:

MRd_Hdr为24B，PL_Hdr为20B

设备的PCIe配置，例如，具有8个通道(x8)的PCIe Gen 3设备，为我们提供了可用带宽以及MPS和MRRS的值。利用上面的公式，我们可以计算不同传输大小的有效带宽。图1中的有效PCIe带宽图就是使用该模型计算的，其假设一个PCIe Gen 3 x8设备，MPS = 256B，MRRS = 512B，使用64位寻址。锯齿图形显示了每个MPS字节数据的额外的DLL/TLP头的开销，对于较小的传输大小时这个开销将更高。该图还显示了MRRS的影响，因为额外的MRd TLP消耗带宽，否则MrR事务将会使用这些带宽。

该模型还允许我们计算更加复杂的设备/主机交互的开销。例如，对于图1中的Simple NIC图，我们计算了简单NIC的数据包发送和接收所用的PCIe带宽。对于发送，驱动程序写入并更新设备上的发送队列尾指针(4B PCIe写入)。然后，设备以DMA方式发送描述符(16B PCIe读取)，并随后，将数据包缓冲。在传输后，设备产生中断(4B PCIe写)，驱动程序读取发送队列头指针(4B PCIe读)。对于接收，驱动程序更新接收队列尾指针，并将缓冲区排入自由列表(4B PCIe写)。然后，该设备将空闲列表描述符(16B PCIe读)、数据包(PCIe写)和RX描述符(16B PCIe写)以DMA方式发送到主机，并产生一个中断(4B PCIe写)。最后，驱动程序读取接收队列头指针(4B PCIe读取)。然后，该模型计算将每个事务的开销，并计算可实现的带宽。

上述的NIC模型非常简单，所有现代NIC都部署了各种优化。例如，Intel Niantic NIC [19]可以从主机中批量分配多达40个传输描述符，并可以将多达8个TX描述符批量写回主机。图1中的优化NIC(内核驱动程序)显示了这些优化对简单NIC模型的性能影响。通过更改驱动程序，吞吐量可以进一步提高，如同一图中的优化NIC(DPDK驱动程序)所示。Intel DPDK驱动程序对设备的配置有所不同:不会产生中断，并且驱动程序不会读取设备寄存器来确定是否已接收/发送数据包。优化NIC的图表显示，即使只在设备和驱动程序端进行适度优化，也能显著提高可实现的吞吐量。

我们的PCIe模型不只可以用来计算NIC的可实现吞吐量。它同样可以用于以编程的方式对任何PCIe器件进行建模，前提是可以获得一些细节，这些细节通常可以从器件驱动程序或数据手册中获得。此外，在设计定制NIC功能时，该模型可以而且已经用于快速评估替代方案的影响。该模型有一些局限性:一些较低级别的PCIe开销，特别是流量控制消息，仅基于PCIe规范进行估计，并且该模型略微高估了它们的影响。此外，该模型没有考虑未对齐的DMA读的PCIe开销。为此，需要规范要求第一个带数据完成包将剩余的带数据完成包与通告的读取完成边界(RCB，通常为64B)对齐，而未对齐的PCIe读取可能会产生额外的TLP。

PCIE-BENCH方法

虽然PCIe协议栈相对容易建模，但它是DMA引擎的实现，特别是PCIe根复合体的复杂性增加(在第2节中讨论)，这使得在实际系统中很难评估端到端PCIe性能。因此，我们本着lmbench [39]和hbench:OS [5]的精神设计了一套PCIe微基准。其主要思想是执行从设备到主机内存缓冲区的单个PCIe操作，同时仔细控制可能影响性能的参数。

图3显示了主机缓冲区设置和决定从PCIe设备访问的参数。我们在主机上定义一个(逻辑上)连续的缓冲区。该缓冲器可以在DMA地址空间中是连续的，或者由多个较小的缓冲器组成。它必须明显大于Last Level Cache (LLC)的大小，因为在某些体系结构中，PCIe根复合体与CPU的高速缓存系统相接。为了测量缓存效果，只需重复访问主机缓冲区的一个子集，即窗口大小。

对于给定的微基准，我们使用多个DMA请求访问主机缓冲区的窗口大小，并保持每个请求传输的数据量固定(传输大小)。DMA可以从主机的cache line的一个偏移开始，允许我们确定是否有任何未对齐访问的惩罚。为了确保每个DMA请求触及相同数量的cache lines，窗口被分成大小相等的单元。每个单元是偏移量和传输大小的总和，向上舍入到下一个cache line。微基准通常可以被配置为顺序地或随机地访问单元(access pattern)，尽管在本文中的大多数实验中，我们使用随机访问。对于每个基准测试，都需要仔细控制CPU缓存的状态。默认情况下，缓存在每个基准测试之前都经过反复测试，以确保冷高速缓存。或者，我们可以尝试从主机、通过写入窗口(主机预热)或从设备来预热缓存。后者是通过在运行测试之前向窗口(设备热态)发出多个DMA写来实现的。了解主机缓存系统的影响很重要:当从主机传输数据包时，通常至少数据包报头是驻留在缓存中的，当从网络接收时，数据包数据可能会被DMA到non-cache resident buffers，这取决于缓存的总体压力。最后，需要控制主机缓冲区的位置。在集成了PCIe和内存控制器的SMP系统中，整个主机缓冲区要么分配给PCIe设备所连接的本地节点，要么分配给不同的(非本地)节点。

4.1延迟基准

第一套PCIe 微基准测量单个PCIe操作的延迟。在大多数可编程硬件上，测量(来自设备的)PCIe存储器读事务(MRd)的延迟相对容易:在发出DMA读之前获取一个时间戳，在DMA引擎发出DMA读完成信号时获取另一个时间戳，然后记录时差。DMA读延迟基准自始至终都标有LAT_RD。

由于PCIe存储器写(MWr)事务是posted传送方式，因此无法从设备直接测量DMA内存写入的延迟:它们在发送时没有明确确认成功。相反，我们通过从同一个地址发出一个DMA写操作，然后发出DMA读操作，来间接测量写操作的延迟。PCIe排序确保了PCIe根复合体先处理写操作后处理读操作。注意，这种方法不允许我们单独计算DMA写操作的延迟，因为DMA读操作的延迟可能会受到前面DMA写操作的影响。这些基准测试的结果被标记为LAT_WRRD。对于延迟基准，我们记录每个事务的延迟，然后计算平均值、中间值、最小值、最大值、第95和第99百分位。

延迟测量允许我们评估缓存和IO-TLB损失的成本，或从PCIe设备访问远程内存的额外延迟。虽然我们不能直接测量DMA写操作的延迟，但是DMA写操作之后对同一地址进行DMA读操作的延迟提供了对技术的深入了解，例如DDIO。测量延迟包括也设备开销，例如发出DMA请求或接收完成通知的成本。因此，当观察PCIe根复合体的影响时，研究延迟的相对变化比研究绝对延迟值更有见地。

正如第2节所强调的，在为可编程NIC编写软件或在(可重新配置的)逻辑中实现DMA引擎时，延迟测量特别重要:图2中测量的延迟远远超过了小数据包的包间时间。测得的延迟及其方差决定了需要处理多少飞行中的DMA。

4.2带宽基准

第二套PCIe微观基准侧重于带宽。DMA带宽是通过在开始时获取时间戳，发出大量的DMA并在结束时获取时间戳来测量的。带宽可以通过时差和传输的数据量来计算。我们对DMA读和DMA写的带宽感兴趣(分别将其标为BW_RD和BW_WR)。为了测量双向带宽，我们交替发布DMA读和DMA写事务（标记为BW_RDWR）。这确保了PCIe MRd事务层包与PCIe Mr事务层包竞争根复合体的带宽。

带宽基准，尤其是传输大小较小和随机访问模式的带宽基准，会给系统带来很大的负载。如果DMA引擎可以用64字节的传输使PCIe链路饱和，这将在每个方向上每秒产生大约6950万个事务，使得根复合体要每5ns处理一个事务。因此，带宽微基准可以揭示出根复合体设备中的限制，并且指出设备的DMA引擎的实现。

实现

pcie-bench方法需要对PCIe设备的DMA引擎进行编程和细粒度控制。我们已经在Netronome的商用板和面向研究的NetFPGA板上实施了该方法。同一方法的两个独立实现验证了我们针对不同主机体系结构的性能测量，并提供了对两个不同PCIe实现的直接观察。

5.1 Netronome NFP实现

Netronome提供了许多基于NFP-6000和NFP-4000以太网控制器的高度可编程网卡[44，45，59]。这些以太网控制器具有多达120个八路多线程流处理内核(FPCs)、一个分层内存子系统和完全可编程的PCIe接口，所有这些都通过分布式交换结构互连。PCIe子系统向FPCs公开了两个接口:一个命令接口，允许内核直接从寄存器发出小的PCIe读写事务；一个大容量的DMA接口，允许FPCs在主机存储器和NFP上的存储器之间进行排列的大规模传输。PCIe 微基准通过这两种接口作为固件在FPCs上实现。这个微基准在基于NFP-4000和NFP-6000的控制器上都有效。

Firmware.完整的PCIe微基准测试套件在单个固件映像中实现。它提供了一个简单的控制界面，允许主机上的用户空间程序选择运行哪种类型的基准，并提供必要的配置参数，如主机缓冲区位置、传输大小等。基准测试结果被写入NFP存储器，在那里可以从主机上读回。

延迟测试在其中一个FPCs中的单个线程上运行。这个线程计算下一个要使用的主机地址，并准备一个DMA描述符。然后，该线程读取内部时间戳计数器的当前值，并将DMA描述符排入DMA引擎。一旦本次DMA完成，DMA引擎就向线程发送信号，线程获取另一个时间戳，并将差异记录到NFP的内存中。延迟基准测试的一个变体是使用直接PCIe命令接口，这种接口适用于小型传输(最高128字节)。使用这种变体，该线程可以直接发出PCIe读或写命令，并在完成时得到信号，而不是构建和排列一个DMA描述符。时间戳计数器每16个时钟周期递增一次，在1.2 GHz NFP上，提供19.2纳秒的分辨率。对于延迟基准，我们通常记录200万个事务的时间。

对于DMA带宽测试来说，挑战在于确保DMA描述符能以比其排出队列更高的速率排入到DMA引擎。为了实现这一点，对于较小的传输大小，我们使用12个内核和8个线程作为DMA工作线程。在一个循环中，每个DMA工作线程计算一个主机地址，准备一个DMA描述符并将其排列，直到完成为止。所有DMA工作线程所共享的原子计数器在发出新的DMA请求之前会递减。如果计数器值低于零，工作线程停止。对于BW_RDWR测试，如果计数器为偶数，则每个工作线程发出一个DMA读，如果计数器为奇数，则发出一个DMA写。控制线程用于启动所有工作线程并等待它们完成。经过的时间用于计算获得的带宽。对于带宽测试，执行800万次DMA请求。对于DMA延迟和带宽测试，DMA描述符被配置为以内部256 KB SRAM为目标，称为群集目标存储器（Cluster Target Memory）。该存储器的存取延迟为50-100个周期。将DMA描述符入队会导致类似的延迟。这些延迟增加了每次DMA传输的固定损耗，虽然它们是针对NFP的，但我们预计其他可编程网卡也会有类似的开销。该Firmware是在Micro-C中实现的，这是NFP的专用扩展。微基准测试套件用大约1500行代码实现，核心需要大约500行代码。代码可以在没有外部依赖的情况下编译，在基于NFP6000和NFP4000的网卡上运行。

5.2 NetFPGA

NetFPGA是一个开源社区平台[43]。它由尖端的可重新配置板、参考软件和硬件设计以及设计开发和验证基础设施支持。最新一代的NetFPGA板是NetFPGA-SUME，它是一个PCIe主机适配卡[62]，能够达到100Gb/s的应用速度。该板利用了一个大型Xilinx Virtex-7 FPGA器件，集成了两个PCIe Gen 3硬盘，以及QDRII+和DDR3内存类型等资源。

Hardware. PCIe微基准测试套件可以直接在FPGA上实现。它通过pcie-bench功能增强了描述的DMA引擎[61]。该系统提供了一个简单的控制界面，允许主机选择运行哪个微基准及其参数。该系统通过一个自由运行的计数器记录时间，以PCIe核心频率(250MHz)运行，提供4ns的分辨率。每当软件触发一个新的微基准时，编码在硬件中的有限状态机就会计算主机地址并产生相关的存储器读或写请求。该设计不使用先进先出排队DMA请求，而是直接将DMA请求传递给DMA引擎。所有的存储器请求都是动态生成的，因为硬件设计允许每个时钟周期传输一个新的请求。

对于延迟测试，系统被配置为在DMA读之前和接收到确认信号之后获取时间戳。系统最多记录1000个延迟值。对于带宽测试，系统测量执行100万次事务所需的总时间。基准测试结果在基准测试运行后被写入到NetFPGA存储器中，在那里可以从主机上读回。该FPGA设计是用Verilog和System Verilog编写的。微基准套件用大约1200行代码实现。它可以被编入NetFPGA-SUME和Xilinx VC709板。

5.3内核驱动程序

NFP和NetFPGA设备都使用内核驱动程序来初始化硬件，为DMA分配主机内存，并提供对用户空间程序的访问，以控制基准的执行和收集结果。NFP pcie-bench驱动程序使用标准的NFP内核驱动程序。它以4MB的块来分配主机端的DMA缓冲区，因为这是在大多数Linux内核版本中可以物理上连续分配的最大大小。NetFPGA驱动程序从大容量内存(1GB页面)或标准4KB系统页面中分配内存。hugetlbfs是默认选项，因为它允许轻松分配大的、物理上连续的内存区域。两个驱动程序都提供了对从哪个NUMA节点分配内存的控制，并导出了一个接口，允许用户空间程序用主机DMA缓冲区的受控部分来预热缓存。NFP pcie-bench内核模块用大约400行代码实现，而NetFPGA驱动程序用大约800行代码实现。

5.4控制程序

在这两种实现中，基准的执行、数据的收集和结果的后处理都是由用户空间程序执行的。NFP实现使用一个Python程序和一个用C语言编写的小工具来处理缓存变暖。Python程序可以用来运行单独的测试或一整套测试。一次完整的运行大约需要4个小时，执行大约2500个单独的测试。对于延迟基准，控制程序读取单个事务的计时数据，并计算各种指标，如平均值、中值、最小值、最大值以及第95和第99百分位。可选地，它生成数据的CDF、直方图和时间序列。对于带宽测试，控制程序计算带宽和事务速率。它用1600行Python和120行C代码实现。

NetFPGA控制程序用大约600行C代码实现，并提供一个命令行界面来控制各个测试参数。原始测试结果被写入一个文件进行进一步处理。

5.5在其他设备上的实现

pcie-bench最好在PCIe设备上实现，提供对DMA引擎的编程、细粒度控制，如上述的Netronome NFP和NetFPGA。具有类似功能的PCIe卡越来越多。例如，Intel Xeon Phi coprocessor揭露了设备的DMA引擎通过描述符环连接到Phi的核心和主机[18]。还有越来越多的集成FPGA的可编程网卡，例如已经提到了的Exablaze NIC[11]和Mellanox的可编程ConnectX-3 Pro [40]。在这些设备上实现pcie-bench应该需要与之前的两个实现大致相同的工作量。

pcie-bench的某些有限方面可能通过仔细控制数据包发送和接收缓冲区的位置，进而以环回模式在不可编程的商用网卡上实现。例如，可以重复地将相同的分组缓冲器排队用于传输，并改变自由列表缓冲器，以将接收到的分组定向到可变窗口大小(反之亦然)。延迟或带宽的相对变化可以提供对主机端PCIe实现的一些观察，并且改变缓冲区地址的对齐可以揭示设备的DMA引擎的限制。但是，请注意，由于商用网卡的测量总是包括描述符传输的开销，因此结果可能不如可编程PCIe器件所获得的结果准确。

实验评估

本节报告pcie-bench套件的运行情况。表1列出了用于本文评估结果的系统细节。我们专注于围绕Intel Xeon E5 processors构建的系统，因为在撰写本文时，这是数据中心服务器中最常用的配置[55]。我们讨论了几代Xeon E5 processors的比较结果，但也包括来自Intel Xeon E3系统的一些数据，以比较不同处理器架构的结果。对于所有实验，我们使用PCIe Gen 3 x8配置，因为它是现代网卡的默认配置。一旦硬件可用，我们希望pcie-bench的方法同样适用于其他PCIe配置，包括下一代PCIe Gen 4。

6.1基线带宽和延迟

作为第一组结果，我们在图4中展示了NFP-6000和NetFPGA的基线吞吐量。我们将其与40Gb/s以太网所需的带宽以及PCIe Gen 3设备可实现吞吐量的简化模型进行了比较。该模型准确地计算了PCIe的物理、数据链路和事务层的损害，但仅估计了流量控制消息的损害。我们针对固定的8KB主机缓冲区测量了不同传输大小的PCIe读、写和交替读/写传输的吞吐量，该缓冲区在每次测试前都会预热，以消除所有缓存影响。我们将传输大小从64B变化到2048B，大致以2的幂为增量，但在重要的传输大小(如一些cache line或TLP大小边界)周围用-1/+1B进行额外测量。所有直接存储器存取起始地址都是高速缓存行对齐的，所有测试都在同一个Xeon E5 2637v3系统上执行，以消除系统配置中的任何差异。图4显示了测试结果。

在所有三个数据集中，pcie-bench的NetFPGA实现严格遵循用我们的模型计算的PCIe带宽。但对于PCIe写，NetFPGA实现实现了稍高的吞吐量。这是因为该模型假设流量控制消息的开销是固定的，对于单向流量，这不会影响流量吞吐量。pcie-bench的NFP实现通常比NetFPGA实现的吞吐量略低(但通常可以达到足以支持40Gb/s以太网速率的吞吐量)。主要原因是NetFPGA实现直接从内部FPGA存储器驱动DMA引擎，不执行任何额外的处理。在NFP实现中，DMA引擎还必须将数据从主机传输到内部SRAM，然后再将其传输到NFP内部存储器，在那里它可以被NFP卡的FPCs访问。这些额外的开销，以及所需的缓冲区管理和信令，会带来轻微的性能下降。最后，值得注意的是，每个图都显示，对于小数据包大小，两种实现都无法实现以线速传输40Gb/s以太网所需的读取吞吐量。

接下来，我们看一下改变传输大小的单个DMA事务的延迟(图5)。该设置与上述带宽结果相同。总体而言，NFP-6000和NetFPGA的延迟数是相同数量级的，这表明大部分延迟可归因于通用PCIe和总体主机开销。我们测量的四代英特尔处理器的延迟非常相似，也符合第二节中使用ExaNIC测量的延迟。

在NFP-6000上，DMA请求的延迟较高，对于较小的传输，初始固定偏移约为100ns，对于较大的传输，间隔会增大。原因有两个。固定偏移可以用将DMA描述符排入DMA引擎的开销来解释，这在NetFPGA实现中是可以避免的。当使用NFP的直接PCIe命令接口时，NFP-6000实现了与NetFPGA相同的延迟，这进一步表明大部分延迟可归因于主机系统。随着转移规模的增加，差距的扩大可以通过考虑NFP的内部结构来解释(5.1)。主机的每次DMA传输都会导致从SRAM到NFP内部存储器的额外传输。这种额外的传输会根据传输大小增加延迟，但这有助于将DMA请求与FPCs执行的(可变)数据包处理时间分离开来。

6.2比较架构

图5显示，Intel Xeon E5系统的最小和第95百分位内存延迟非常接近中位延迟，这表明PCIe事务所经历的延迟差异很小。图6显示了与CDF相同的系统(NFP6000-NFP)的64B DMA读的延迟分布。该图证实，99.9%的交易都在80ns的狭窄范围内，从最小520ns开始，中间值为547ns。200万个事务中的最大延迟为947ns。

该图还显示了同代处理器(NFP6000-HSW-E3)的Xeon E3系统的结果。该结果与Xeon E5系统形成鲜明对比。Xeon E3系统的最小延迟实际上低于493ns，但是中位数是1213ns的两倍多。此外，从大约第63百分位开始，潜伏期急剧增加，第90百分位是中间值的两倍，第99百分位是5707ns。第99.9百分位(11987ns)比中间值大一个数量级，大多数延迟超过1ms，最大延迟为5.8ms。

这种差异也反映在带宽基准(未显示)中，对于DMA读，对于大于512B的传输，Xeon E3系统仅匹配Xeon E5系统，对于DMA写，对于任何传输大小，都无法达到40Gb/s以太网所需的吞吐量。

我们只能推测这种不同行为的原因。英特尔似乎有可能为其Xeon E5和Xeon E3系列处理器保留完全不同的PCIe根复合体设备。更详细地看一下Xeon E3的数据，较长延迟的出现没有规律可循。我们怀疑，特别是较大的延迟可能与隐藏的节能模式有关。在禁用BIOS中的节能模式之前，我们已经在Xeon E5系统上观察到大的延迟(< 1ms)。但是，在Xeon E3系统上禁用它们并没有显著改变延迟分布。

6.3 Caching and DDIO

我们现在研究caching和DDIO对PCIe事务的影响。对于这些实验，我们保持所有参数不变，除了窗口大小和LLC的状态。窗口大小从4KB到64MB不等，这将超过了我们所有系统上LLC的15MB或25MB。

首先，我们看一下PCIe传输延迟。为了测量延迟，我们使用8字节事务的NFP 的PCIe命令接口，因为这是我们现有的最低延迟操作。如第4.1节所述，我们确保每个后续事务都触及不同的缓存行。结果如图7(a)所示。对于具有冷缓存的PCIe读(LAT_RD)，当我们更改窗口大小时，我们看不到延迟的变化:所有PCIe读都是从存储器中进行的。当缓存较热时，读取延迟约低于70ns，但一旦窗口大小超过LLC的大小，读取延迟就会增加。这确认了如果数据驻留在cache中，则从LLC服务PCIe读取。对于热缓存，发布的PCIe写操作之后接读操作的延迟大致遵循相同的模式:写操作和读操作都会命中LLC，一旦窗口大小超过LLC的大小，延迟就会增加约70ns。对于冷缓存，LAT_WRRD结果说明了DDIO的影响:对于小窗口大小，分配新的缓存行，并对缓存执行写入(和后续读取)。一旦窗口大小超过为DDIO保留的LLC的10%，在写入成功之前，必须将dirty cache lines刷新到存储器中，这导致大多数写入延迟70纳秒。对于较大的传输大小，命中或未命中cache之间的差异显著减小:对于64B LAT_WRRD测试，差异约为10ns。

图7(b)中的带宽数据显示了类似的情况。对于64B 的DMA读(BW_RD)，如果数据已经驻留在LLC中，则有可测量的好处。对于较大的传输大小(未显示)，好处较小，并且从512 B的DMA读开始，没有可测量的差异。对于DMA写操作(BW_WR)，无论数据是否驻留在cache中，都没有任何好处。将窗口大小保持在LLC的10%以下也没有可衡量的好处。我们怀疑cache的DDIO部分清理得不够快，所以所有的DMA写要么命中主LLC，要么命中DDIO部分。由于不能禁用DDIO，并且没有专用的性能计数器，因此无法验证这一假设。

6.4 NUMA 影响

由于PCIe根复合体和存储器控制器集成在每个CPU节点中，因此PCIe设备可以访问它所连接的节点的本地或远程存储器。在本节中，我们将评估这种非均匀内存访问对性能的影响。主机缓冲区在PCIe设备连接的节点(本地)或双向NUMA系统中的另一个节点(远程)上分配。cache在分配缓冲区的节点上被加热或搅动。

图8显示了在具有热缓存的不同窗口大小上，对于不同的传输大小，本地内存与远程内存的DMA读取带宽的百分比变化。64B的DMA读的吞吐量下降了20%(从32Gb/s降至25Gb/s)。一旦DMAs不再从本地缓存中得到服务，这一差异将降至10%左右。对于128和256 B的DMA读，访问远程存储器的代价下降到5-7%(例如，从128字节的44Gb/s降至41Gb/s)。512B的DMA读没有明显的损失。数据由冷缓存DMA读吞吐量(未显示)确认，其中远程64B读取经历恒定的10%惩罚(128B和256B读取为5%)。

DMA写的吞吐量似乎不受主机缓冲区的局部性或主机缓冲区的大小的影响。与英特尔规范[20]形成对比的是，我们认为所有DMA写操作最初都可能由本地DDIO缓存处理。

为了完整起见，除了远程访问给我们的系统增加了恒定的100ns的延迟之外，延迟数字与图5和图7所示的本地情况没有太大区别。总的来说，我们的两个双插槽系统(NFP6000_BDW和NFP6000_IB)的结果是相同的，表明在将它们分开的两代系统中几乎没有什么变化。

6.5 IOMMU影响

最后，我们来看看在PCIe设备和主机之间的数据路径中插入一个IOMMU的影响。为了衡量IOMMU的影响，我们在intel_iommu=on的情况下在Linux内核命令行上启用它。Ivy Bridge和更新架构中的IOMMU设备支持超级页面，以减少页面表条目的数量，从而减少TLB条目的数量。在我们的实验中，我们禁用了这种行为(通过在内核命令行中指定sp_off)。这迫使我们使用4KB的页表条目，并允许我们在实验中使用相对较小的64MB主机缓冲区。

图9显示了不同传输大小的结果。与第6.4节中给出的数据一样，该图显示了在没有IOMMU的情况下，相同实验运行的百分比变化。对于小窗口尺寸，在传输尺寸范围内没有可测量的差异。但是，一旦窗口大小增加到超过256KB，吞吐量就会急剧下降。对于64B DMA读，它下降了几乎70%，甚至对于256B DMA，下降仍然是显著的30%。512B及以上的传输尺寸没有变化。对于DMA写(未显示)，下降幅度并不太大(64B写入为55%)，但仍然非常显著。

根据这些数据，我们得出结论，在特定的系统上，IO-TLB有64个条目(256KB/4KB)，这个数字不是由英特尔发布。64B读取的延迟从大约430ns增加到760ns，使IO-TLB未命中和随后的页表遍历的成本大约为330ns。对于较小的传输大小，与传输数据所需的时间相比，这种代价相对较高，因此对吞吐量的影响更大。在我们运行实验的所有4代英特尔微体系结构中，数据惊人地一致，并且我们观察到了与我们的NetFPGA pcie-bench实现相同的效果。在四代微体系结构中取得了如此一致的结果，我们得出结论，自首次实施以来，英特尔的IOMMUs几乎没有什么发展。

经验教训和使用案例

从pcie-bench获得的结果可以并且已经被用于为高性能I/O表征和调整系统软件。有太多复杂的工具来分析操作系统和应用程序性能，例如[14，21]，以及理解主机CPU架构和OS原语的性能影响的工具，例如[5，39]。然而，这些工具都不能提供对I/O子系统性能的详细观察。pcie-bench提供必要的数据来微调专用网络堆栈[37，38]，并优化内核IOMMU处理[48]。

表2报告了本文的显著发现，这些发现是通过pcie-bench实验得出的。基于IOMMU数据，我们强烈建议使用超级页面，并尝试强制使用于DMA的IO缓冲区尽可能位于少数几个超级页面中。这在精心控制的环境中是可能的，例如虚拟化网络设备。但是，在为虚拟机（VM）提供指定的PCIe设备的多租户虚拟机环境中，目前还无法通过英特尔的IOMMUs充分隔离虚拟机的IO性能。

对于NUMA体系结构，我们发现从远程缓存中进行小规模的DMA读比从本地缓存中读取要昂贵得多。访问远程节点上的数据也会增加大约100ns的延迟。虽然将小型网络数据包“pin”到本地节点可能不可行，但在本地节点上定位数据结构(如描述符环)肯定会很有用。我们的数据表明，对于较大的数据包，数据包缓冲区的位置并不重要，建议在进行处理的节点上分配数据。

最后，我们的测量结果证实了DDIO的记录操作，并表明对于小的传输，缓存驻留数据的访问速度大约快70ns。我们看到了两个对网络应用有益的领域。首先，对描述符环的访问延迟较低，因此开销较小。其次，高速缓存的集成应该有利于小分组接收，特别是对于不是高速缓存线倍数的分组大小(例如，64B Ethernet frames with the 4B FCS stripped)。由于数据是直接DMA到高速缓存的，因此在DMA成功之前，dirty cachelines不需要写回存储器。

虽然上述课程侧重于优化主机系统软件，但通过pcie-bench获得的见解也对不断增长的研究领域产生了影响，这些研究领域正从简单的TCP卸载转向将更复杂的处理卸载到可编程和可重新配置的网卡，例如[2，26，51，52]。为了实现这些应用卸载的固件或可重新配置的逻辑，对DMA引擎及其与主机系统的交互进行详细描述是很重要的。pcie-bench提供的数据是指导此类实施选择的理想选择。例如，了解Netronome板的事务延迟严重影响了提供不同网络处理负载的多个固件实现的设计。延迟数据决定了固件必须处理多少个传输中的DMA(对于分组数据DMA和描述符DMA)才能维持线路速率。反过来，这决定了I/O结构的大小，例如环和其他用于动态内存分配的存储，以及指定适当数量的Flow Processing Cores和线程。延迟和带宽数据还决定了固件和操作系统中相应设备驱动程序执行的批处理量。例如，在NFP6000-HSW系统中，从主机向设备传输128 B的数据需要560到666ns。对于128B数据包，以40Gb/s的线路速率，每29.6ns需要传输一个新数据包。这意味着固件和DMA引擎需要处理至少30个正在运行的事务。这些计算可以扩展到考虑描述符传输的延迟，并计算出每个DMA的周期预算。如果启用了IOMMU，固件和DMA引擎还需要覆盖因IOMMU TLB未命中而导致的330ns的偶尔延迟增加。此外，我们还发现一些系统的延迟差异很大，尤其是Xeon E3系统，这使得高性能固件或DMA引擎设计的实现更加复杂。

最后，工程师们可以使用pcie-bench方法和测量来评估现有设计，并得知DMA引擎未来架构的目标。例如，PCIe延迟测量被用来评估一套NetFPGA DMA引擎设计的每次迭代。能够将当前设计与来自其他实现的数据进行比较，有助于确定性能瓶颈是由于主机架构中的工件还是设计限制造成的。更重要的是，这种方法也被广泛用于芯片组装过程中的验证，并指导未来Netronome芯片的架构决策。pcie-bench提供的使用微基准是理想的，因为它们提供了通过其他方式无法获得的详细的和受控的数据。

相关工作

几篇论文观察了PCIe及其在高性能网络应用环境中与主机架构的交互。Kalia等人[24]为RDMA primitives以及他们如何与PCIe互动提供了一个低层次的评估和建议。Li等人[32]讨论了DDIO对现代Key-Value-Store (KVS)应用程序性能的好处。Lim等人[34]针对高性能KVS应用讨论了NUMA对设备DMA的影响，Han等人[17]针对GPU加速的数据包处理讨论了这种影响。所有这些都涉及到本文所涉及的一些方面，但都是在一些更高层次的应用环境中进行的。相比之下，pcie-bench允许对pcie性能特征进行系统研究。所获得的结果可用于详细解释应用程序性能行为，并可更准确地指导未来的应用程序的性能改进。

至于关于PCIe的更一般的研究，除了米勒等人[41]描述了一种通过对事务延迟的差分分析来测量PCI和第一代PCIe互连延迟的方法之外，几乎没有微基准工作。Moll等人[42]演示了基于FPGA的硬件在分析软件应用方面的应用，包括对PCI总线性能的分析，而Endo等人[10]演示了延迟在交互式和事务性应用软件中的重要性。此外，他们引入了一套新的微基准来评估延迟性能，并鼓励对PCI互连延迟影响进行进一步的特定于应用的研究。

Lostrie等人[36]调查了PCIe的专用案例，提出了一种利用微通道技术对两个FPGA板之间的全部PCI通信路径的性能进行基准测试的设置。而Koop等人[27]在PCIe 2.0系统上评估无限带宽。作者研究了PCIe 2.0在Mellanox ConnectX上的DDR和QDR数据速率方面的优势，还研究了多核机器上附加互连带宽对应用性能影响的一般趋势。更早些时候，Liu等人[35]评估了Mellanox的第三代InfiniBand HCAs，它PCIe支持接口。他们将这些与使用PCI-X接口的HCAs的性能进行了比较。评估由互连级别的一组微基准组成，包括延迟、带宽和双向带宽实验。它们表明，带有PCIe接口的InfiniBand HCAs具有出色的性能。然而，这种方法与我们自己的方法只是表面上的相似，我们的方法坚定地关注InfiniBand的性能。

最后，Braithwaite [4]和Li等人[33]研究了NUMA体系结构中的I/O带宽。前者提供了一种分析现代AMD和Intel NUMA架构的主存储器和PCIe数据访问特性的方法。他们还展示了数据访问性能模型的综合，旨在量化这些架构特性对带宽的影响。Li等人进一步提供了最先进的NUMA主机的特征，并提出了一种使用存储器语义来模拟I/O操作的方法，进而对I/O带宽性能进行建模。在这两种情况下，这些努力都无法深入了解PCIe和现代NUMA架构之间的那明确又不断发展的关系。

结论和未来工作

本文表明，除了与根复合体和设备驱动程序的交互之外，PCIe还会显著影响终端主机网络的性能。过去的研究已经报告了在特定应用背景下的一些发现，例如RDMA和KVS加速。相反，我们提供了一个理论模型和方法，pcie-bench，来理解和研究PCIe协议的内在瓶颈。我们还介绍了在真实系统中系统评估和表征PCIe器件的两种实现。

除了pcie-bench的设计和实现，我们还讨论了一些系统的特性结果。我们分享学到的经验教训，希望对当前的软件系统和未来的硬件设计有所启示。我们的研究允许探索新的PCIe和主机体系结构特性(如DDIO和IOMMUs)的影响。具体来说，我们证明了PCIe与DDIO高速缓存的集成工作良好，但同时也说明了Intel IOMMUs和NUMA在需要高DMA速率时可能产生的显著影响(有时是不受欢迎的)。

我们的初步结果表明，我们还需要做更多的工作。鉴于Xeon E5和Xeon E3系统在PCIe性能上的显著差异，如果对不同架构(例如AMD、ARM64和Power based servers)进行更详细的研究，将会为PCIe实施提供更有意义的见解。此外，我们还没有研究在同一台服务器上安装多个高性能PCIe设备的影响，这是数据中心的常见配置。此类研究将揭示对IOMMUs实施的进一步洞察(例如，设备之间是否共享IO-TLB条目)，并有可能进一步挖掘PCIe根复合体实施中的瓶颈。

致谢

这项研究(部分)得到了英国工程和物理科学研究委员会(EPSRC)在EARL项目(EP/P025374/1)和欧洲H2020项目dReDBox(批准号687632)和METRO-HAUL(批准号761727)下的支持。

参考文献

[1] Hitesh Ballani, Paolo Costa, Christos Gkantsidis, Matthew P. Grosvenor, Thomas Karagiannis, Lazaros Koromilas, and Greg O’Shea. 2015. Enabling End-Host Network Functions. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[2] Hitesh Ballani, Paolo Costa, Christos Gkantsidis, Matthew P. Grosvenor, Thomas Karagiannis, Lazaros Koromilas, and Greg O’Shea. 2015. Enabling End-Host Network Functions. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[3] Nicola Bonelli, Andrea Di Pietro, Stefano Giordano, and Gregorio Procissi. 2012. On multi–gigabit packet capturing with multi-core commodity hardware. In Passive and Active Measurement (PAM). Springer.

[4] Ryan Karl Braithwaite. 2013. NUMA data-access bandwidth characterization and modeling. Master’s thesis. Virginia Polytechnic Institute and State University, US.

[5] Aaron B. Brown and Margo I. Seltzer. 1997. Operating system benchmarking in the wake of Lmbench: a case study of the performance of NetBSD on the Intel x86 architecture. In Special Interest Group for the Computer Systems Performance Evaluation Community (SIGMETRICS). ACM.

[6] Martin Casado, Teemu Koponen, Scott Shenker, and Amin Tootoonchian. 2012. Fabric: A Retrospective on Evolving SDN. In Hot Topics in Software Defined Networks (HotSDN). ACM.

[7] Colin Dixon, Hardeep Uppal, Vjekoslav Brajkovic, Dane Brandon, Thomas Anderson, and Arvind Krishnamurthy. 2011. ETTM: A Scalable Fault Tolerant Network Manager. In Networked Systems Design and Implementation (NSDI). USENIX.

[8] DPDK. 2018. Official website. http://www.dpdk.org.

[9] Peter Druschel, Larry L. Peterson, and Bruce S. Davie. 1994. Experiences with a High-speed Network Adaptor: A Software Perspective. In Conference on Communications Architectures, Protocols and Applications (SIGCOMM). ACM.

[10] Yasuhiro Endo, Zheng Wang, J. Bradley Chen, and Margo Seltzer. 1996. Using latency to evaluate interactive system performance. In Symposium on Operating Systems Design and Implementation (OSDI). ACM.

[11] Exablaze. 2018. Official website. http://www.exablaze.com.

[12] Daniel Firestone. 2018. Building Hardware-Accelerated Networks at Scale in the Cloud. https://conferences.sigcomm.org/sigcomm/2017/ files/program-kbnets/keynote-2.pdf.

[13] Daniel Firestone, Andrew Putnam, Sambhrama Mundkur, Derek Chiou, Alireza Dabagh, Mark Andrewartha, Hari Angepat, Vivek Bhanu, Adrian Caulfield, Eric Chung, Harish K. Chandrappa, Somesh Chaturmohta, Matt Humphrey, Jack Lavier, Norman Lam, Fengfen Liu, Kalin Ovtcharov, Jitu Padhye, Gautham Popuri, Shachar Raindel, Tejas Sapre, Mark Shaw, Gabriel Silva, Madhan Sivakumar, Nisheeth Srivastava, Anshuman Verma, Qasim Zuhair, Deepak Bansal, Doug Burger, Kushagra Vaid, David A. Maltz, and Albert Greenberg. 2018. Azure Accelerated Networking: SmartNICs in the Public Cloud. In Networked Systems Design and Implementation (NSDI). USENIX.

[14] Brandan Greg. 2018. Linux Performance. http://www.brendangregg. com/linuxperf.html.

[15] Prabhat K. Gupta. 2018. Xeon+FPGA Platform for the Data Center. https://www.ece.cmu.edu/~calcm/carl/lib/exe/fetch.php?media= carl15-gupta.pdf.

[16] Sangjin Han, Keon Jang, Aurojit Panda, Shoumik Palkar, Dongsu Han, and Sylvia Ratnasamy. 2015. SoftNIC: A Software NIC to Augment Hardware. In Technical Report No. UCB/EECS-2015-155. University of California at Berkeley.

[17] Sangjin Han, Keon Jang, KyoungSoo Park, and Sue Moon. 2010. PacketShader: A GPU-accelerated Software Router. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[18] Intel. 2014. Xeon Phi Coprocessor System Software Developers Guide. https://software.intel.com/sites/default/files/managed/09/ 07/xeon-phi-coprocessor-system-software-developers-guide.pdf.

[19] Intel. 2018. 82599 10 GbE Controller Datasheet. https: //www.intel.com/content/dam/www/public/us/en/documents/ datasheets/82599-10-gbe-controller-datasheet.pdf.

[20] Intel. 2018. Data Direct I/O technology (Intel DDIO): a primer. http://www.intel.co.uk/content/dam/www/public/us/en/ documents/technology-briefs/data-direct-i-o-technology-brief.pdf.

[21] Intel. 2018. Intel VTune Amplifier 2017. https://software.intel.com/ en-us/intel-vtune-amplifier-xe.

[22] Intel. 2018. Virtualization technology for directed I/O. http://www.intel.co.uk/content/dam/www/public/us/en/documents/ product-specifications/vt-directed-io-spec.pdf.

[23] Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir Ghaemmaghami, Rajendra Gottipati, William Gulland, Robert Hagmann, C. Richard Ho, Doug Hogberg, John Hu, Robert Hundt, Dan Hurt, Julian Ibarz, Aaron Jaffey, Alek Jaworski, Alexander Kaplan, Harshit Khaitan, Daniel Killebrew, Andy Koch, Naveen Kumar, Steve Lacy, James Laudon, James Law, Diemthu Le, Chris Leary, Zhuyuan Liu, Kyle Lucke, Alan Lundin, Gordon MacKean, Adriana Maggiore, Maire Mahony, Kieran Miller, Rahul Nagarajan, Ravi Narayanaswami, Ray Ni, Kathy Nix, Thomas Norrie, Mark Omernick, Narayana Penukonda, Andy Phelps, Jonathan Ross, Matt Ross, Amir Salek, Emad Samadiani, Chris Severn, Gregory Sizikov, Matthew Snelham, Jed Souter, Dan Steinberg, Andy Swing, Mercedes Tan, Gregory Thorson, Bo Tian, Horia Toma, Erick Tuttle, Vijay Vasudevan, Richard Walter, Walter Wang, Eric Wilcox, and Doe Hyun Yoon. 2017. In-Datacenter Performance Analysis of a Tensor Processing Unit. In International Symposium on Computer Architecture (ISCA). ACM/IEEE.

[24] Anuj Kalia, Michael Kaminsky, and David G. Andersen. 2016. Design Guidelines for High Performance RDMA Systems. In Annual Technical Conference (ATC). USENIX.

[25] Thomas Karagiannis, Richard Mortier, and Antony Rowstron. 2008. Network Exception Handlers: Host-network Control in Enterprise Networks. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[26] Antoine Kaufmann, SImon Peter, Naveen Kr. Sharma, Thomas Anderson, and Arvind Krishnamurthy. 2016. High Performance Packet Processing with FlexNIC. In International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). ACM.

[27] Matthew J. Koop, Wei Huang, Karthik Gopalakrishnan, and Dhabaleswar K. Panda. 2008. Performance analysis and evaluation of PCIe 2.0 and quad-data rate InfiniBand. In Symposium on High Performance Interconnects (HOTI). IEEE.

[28] Christoph Lameter. 2013. NUMA (Non-Uniform Memory Access): an overview. In acmqueue. ACM.

[29] Yanfang Le, Hyunseok Chang, Sarit Mukherjee, Limin Wang, Aditya Akella, Michael Swift, and T.V. Lakshman. 2017. UNO: Unifying Host and Smart NIC Offload for Flexible Packet Processing. In Symposium on Cloud Computing (SoCC). ACM.

[30] Ki Suh Lee, Han Wang, and Hakim Weatherspoon. 2013. SoNIC: Precise Realtime Software Access and Control of Wired Networks. In Networked Systems Design and Implementation (NSDI). USENIX Association.

[31] Bojie Li, Zhenyuan Ruan, Wencong Xiao, Yuanwei Lu, Yongqiang Xiong, Andrew Putnam, Enhong Chen, and Lintao Zhang. 2017. KV-Direct: High-Performance In-Memory Key-Value Store with Programmable NIC. In Symposium on Operating Systems Principles (SOSP). ACM.

[32] Sheng Li, Hyeontaek Lim, Victor W. Lee, Jung Ho Ahn, Anuj Kalia, Michael Kaminsky, David G. Andersen, O. Seongil, Sukhan Lee, and Pradeep Dubey. 2015. Architecting to Achieve a Billion Requests Per Second Throughput on a Single Key-value Store Server Platform. In International Symposium on Computer Architecture (ISCA). ACM.

[33] Tan Li, Yufei Ren, Dantong Yu, Shudong Jin, and Thomas Robertazzi. 2013. Characterization of Input/Output bandwidth performance models in NUMA architecture for data intensive applications. In International Conference on Parallel Processing (ICPP). IEEE.

[34] Hyeontaek Lim, Dongsu Han, David G. Andersen, and Michael Kaminsky. 2014. MICA: A Holistic Approach to Fast In-Memory Key-Value Storage. In Networked Systems Design and Implementation (NSDI). USENIX.

[35] Jiuxing Liu, Amith Mamidala, Abhinav Vishnn, and Dhabaleswar K. Panda. 2004. Performance evaluation of InfiniBand with PCI Express. In Symposium on High Performance Interconnects (HOTI). IEEE.

[36] K. Lostrie, P. De Meulenaere, M. Temmerman, N. Van Remortel, and W. Beaumont. 2013. Benchmarking of PCIe-performance in microTCAequipment. In International Conference on P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC). IEEE.

[37] Ilias Marinos, Robert Watson, and Mark Handley. 2014. Network Stack Specialization for Performance. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[38] Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: Rethinking the Stack for High-performance Video Streaming. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[39] Larry McVoy and Carl Staelin. 1996. Lmbench: portable tools for performance analysis. In Annual Technical Conference (ATC). USENIX.

[40] Mellanox. 2018. Programmable ConnectX-3 Pro Adapter Card. https://www.mellanox.com/related-docs/prod_adapter_cards/PB_ Programmable_ConnectX-3_Pro_Card_VPI.pdf.

[41] David J. Miller, Philip M. Watts, and Andrew W. Moore. 2009. Motivating future interconnects: a differential measurement analysis of PCI latency. In Symposium on Architectures for Networking and Communications Systems (ANCS). ACM.

[42] L. Moll and M. Shand. 1997. Systems performance measurement on PCI pamette. In Symposium on FPGA-Based Custom Computing Machines (FCCM). IEEE.

[43] NetFPGA. 2018. Official website. https://www.netfpga.org.

[44] Netronome. 2018. NFP-4000 theory of operation. https: //www.netronome.com/static/app/img/products/silicon-solutions/ WP_NFP4000_TOO.pdf.

[45] Netronome. 2018. Product Brief: NFP-6000 intelligent Ethernet controller family. https://www.netronome.com/static/app/img/products/ silicon-solutions/PB_NFP6000.pdf.

[46] ntop. 2018. PF_RING repository. https://github.com/ntop/PF_RING. git.

[47] PCI-SIG. 2014. PCI Express Base Specification Revision 3.1.

[48] Omer Peleg, Adam Morrison, Benjamin Serebrin, and Dan Tsafrir. 2015. Utilizing the IOMMU Scalably. In Annual Technical Conference (ATC). USENIX.

[49] Ben Pfaff, Justin Pettit, Teemu Koponen, Keith Amidon, Martin Casado, and Scott Shenker. 2009. Extending Networking into the Virtualization Layer. In Hot Topics in Networks (HotNets). ACM.

[50] Ian Pratt and Keir Fraser. 2001. Arsenic: A user-accessible gigabit ethernet interface. In International Conference on Computer Communications (INFOCOM). IEEE.

[51] Andrew Putnam, Adrian M Caulfield, Eric S Chung, Derek Chiou, Kypros Constantinides, John Demme, Hadi Esmaeilzadeh, Jeremy Fowers, Gopi Prashanth Gopal, Jan Gray, et al. 2014. A reconfigurable fabric for accelerating large-scale datacenter services. In International Symposium on Computer Architecture (ISCA). ACM/IEEE.

[52] Sivasankar Radhakrishnan, Yilong Geng, Vimalkumar Jeyakumar, Abdul Kabbani, George Porter, and Amin Vahdat. 2014. SENIC: Scalable NIC for End-host Rate Limiting. In Conference on Networked Systems Design and Implementation (NSDI). USENIX.

[53] Kaushik Kumar Ram, Jayaram Mudigonda, Alan L. Cox, Scott Rixner, Parthasarathy Ranganathan, and Jose Renato Santos. 2010. sNICh: Efficient Last Hop Networking in the Data Center. In Architectures for Networking and Communications Systems (ANCS). ACM.

[54] Luigi Rizzo. 2012. netmap: a novel framework for fast packet I/O. In Annual Technical Conference (ATC). USENIX.

[55] Arjun Roy, Hongyi Zeng, Jasmeet Bagga, George Porter, and Alex C. Snoeren. 2015. Inside the Social Network’s (Datacenter) Network. In Special Interest Group on Data Communication (SIGCOMM). ACM.

[56] Alan Shieh, Srikanth Kandula, and Emin Gun Sirer. 2010. SideCar: Building Programmable Datacenter Networks Without Programmable Switches. In Hot Topics in Networks (HotNets). ACM.

[57] Edward Solari and Brad Congdon. 2003. The Complete PCI Express Reference.

[58] Robert Soulé, Shrutarshi Basu, Robert Kleinberg, Emin Gün Sirer, and Nate Foster. 2013. Managing the Network with Merlin. In Hot Topics in Networks (HotNets). ACM.

[59] Gavin Stark and Sakir Sezer. 2013. NFP-6xxx – A 22nm highperformance network flow processor for 200Gb/s Software Defined Networking. In Symposium on High Performance Chips (Hot Chips). IEEE/ACM.

[60] T. von Eicken, A. Basu, V. Buch, and W. Vogels. 1995. U-Net: A Userlevel Network Interface for Parallel and Distributed Computing. In Symposium on Operating Systems Principles (SOSP). ACM.

[61] Jose Fernando Zazo, Sergio Lopez-Buedo, Yury Audzevich, and Andrew W. Moore. 2015. A PCIe DMA engine to support the virtualization of 40 Gbps FPGA-accelerated network appliances. In International Conference on Reconfigurable Computing and FPGAs (RECONFIG). IEEE.

[62] Noa Zilberman, Yury Audzevich, Adam G. Covington, and Andrew W. Moore. 2014. NetFPGA SUME: toward 100 Gbps as research commodity. In Micro. IEEE.

[63] Noa Zilberman, Matthew Grosvenor, Diana-Andreea Popescu, Neelakandan Manihatty-Bojan, Gianni Antichi, Marcin Wojcik, and Andrew W. Moore. 2017. Where Has My Time Gone?. In Passive and Active Measurement (PAM). Springer.