来源：内容由「网络交换FPGA」编译自「nsdi18」，谢谢。Azure是数据中心的行业标杆，其应用规模和技术都是非常值得借鉴的，文中总结了来自产业界宝贵的经验和教训，探讨为何FPGA是最适合数据中心架构的原因。故翻译此文。
现代云架构依赖于每个运行其自己的网络协议栈的服务器来实现策略，例如虚拟网络的隧道，安全性和负载平衡。但是，随着功能的增加和网络速度的提高，这些网络协议栈变得越来越复杂。在CPU内核上运行这些协议栈会浪费VM（虚拟机）的处理能力，从而增加运行云服务的成本，并增加网络性能的延迟和可变性。
本文介绍了Azure加速网络（AccelNet），这是使用基于FPGA的自定义Azure SmartNIC将主机网络卸载到硬件的解决方案。我们定义了AccelNet的目标，包括与软件可比的可编程性，与硬件可比的性能和效率。我们展示了FPGA是当前用于减轻网络协议栈负担的最佳平台，因为ASIC无法提供足够的可编程性，嵌入式CPU内核也无法提供可扩展的性能，尤其是在单个网络流上。
自2015年底以来，已在所有超过100万台主机的新Azure服务器上部署了实施AccelNet的Azure SmartNIC。自2016年以来，AccelNet服务已向Azure客户提供，提供一致的<15μsVM-VM TCP延迟和32Gbps吞吐量，我们认为这代表了公共云中客户可用的最快网络。我们介绍了AccelNet的设计，包括我们的硬件/软件协同设计模型，关键工作负载的性能结果，以及在基于FPGA的Azure SmartNIC上开发和部署AccelNet的经验教训。
1 引言
公共云是大量且迅速增长的在线软件服务背后的骨干[1,2,3]。仅在Microsoft Azure云中，这些服务就消耗数百万个处理器核心，几EB的存储空间和PB的网络带宽。
带宽和延迟的网络性能对于大多数云工作负载（尤其是面向客户的交互式工作负载）至关重要。 作为一家大型公有云提供商，Azure将其云网络建立在基于主机的软件定义网络（SDN）技术上，利用这些技术实现了几乎所有的虚拟网络功能，如带客户提供的地址空间的私有虚拟网络、可扩展的L4负载均衡器、安全组和访问控制列表等（ACL）、虚拟路由表、带宽计量、QoS等。这些功能由主机平台负责，通常是指在hypervisor中运行的软件。
提供这些服务的成本继续增加。在短短的几年内，我们将网络速度从1GbE提升到40GbE +，增长了40倍以上，并增加了无数新功能。而且，尽管我们构建了日益完善且高效的主机SDN数据包处理功能，但在主机上以软件运行此协议栈需要额外的CPU周期。为这些服务消耗CPU会浪费客户VM可用的处理能力，并增加了提供云服务的总体成本。
有人提出了单根I/O虚拟化（SR-IOV）[4，5]，通过允许从虚拟机直接访问网卡硬件来降低CPU利用率。然而，这种直接访问将绕过主机SDN协议栈，使得网卡负责执行所有的SDN策略。由于这些策略变化很快（几周到几个月），我们需要一个既能提供类似软件的可编程性，又能提供类似硬件的性能的解决方案。
在本文中，我们介绍了Azure加速网络（AccelNet），这是在基于FPGA的Azure SmartNIC上实现的主机SDN协议栈。AccelNet在虚拟化环境中提供基本的网络性能，将数据包处理从主机CPU转移到Azure SmartNIC。基于软件的VFP主机SDN平台[6]和Catapult程序的硬件和软件基础架构[7，8]，AccelNet提供了专用硬件的性能以及在虚拟机管理程序中运行的软件的可编程性。我们的目标是大规模展示我们的设计和在生产中运行AccelNet的经验以及我们吸取的教训。
2 背景
2.1传统主机网络处理
在诸如公共云之类的虚拟化环境的传统设备共享模型中，与物理设备之间的所有网络I / O都将在管理程序的主机软件分区中专门执行。虚拟机发送和接收的每个数据包均由主机网络协议栈中的虚拟交换机（vSwitch）处理。接收数据包通常包括管理程序将每个数据包复制到VM可见的缓冲区中，模拟对VM的软中断，然后允许VM的OS协议栈继续进行网络处理。发送数据包类似，但顺序相反。与非虚拟化环境相比，此额外的主机处理功能：降低性能，要求特权级别进行其他更改，降低吞吐量，增加延迟和延迟可变性以及提高主机CPU利用率。
2.2主机SDN
除了出售虚拟机之外，出售基础设施即服务（IaaS）的云供应商还必须提供丰富的网络语义，例如具有客户提供的地址空间的私有虚拟网络，可伸缩的L4负载均衡器，安全组和ACL，虚拟路由表，带宽计量，QoS等。这些语义非常复杂，而且变化过于频繁，以致于无法在传统交换机硬件中大规模实现它们。而是在vSwitch中的每个主机上实现这些功能。这可以随着服务器数量的扩展而很好地扩展，并使物理网络变得简单，可扩展且非常快。
虚拟过滤平台（VFP）是我们的云级可编程vSwitch，为Azure提供可扩展的SDN策略。它旨在满足Azure的许多SDN应用程序的可编程性需求，为多个SDN控制器提供一个平台，以通过匹配操作表来研究复杂的有状态策略。可以在[6]中找到有关VFP及其如何在Azure中的软件中实现虚拟网络的详细信息。
2.3 SR-IOV
图1：一个带有PF和VF的SR-IOV NIC。
通过使用支持SR-IOV的硬件，可以克服在管理程序中进行数据包处理引起的许多性能瓶颈。符合SR-IOV的硬件为在多个VM之间高效，安全地共享PCI Express（PCIe）设备硬件提供了基于标准的基础。主机连接到特权物理功能（PF），而每个虚拟机连接到其自己的虚拟功能（VF）。VF作为每个硬件的唯一硬件设备公开给VM，允许VM直接访问实际硬件，但仍将VM数据与其他VM隔离。如图1所示，SRIOV NIC包含一个嵌入式交换机，用于根据MAC地址将数据包转发到正确的VF。所有数据包都直接在VM操作系统和VF之间流动，完全绕过主机网络协议栈。这样可以提高吞吐量，降低CPU利用率，降低延迟并提高可伸缩性。
但是，绕过系统管理程序会带来一系列新挑战，因为它也绕过了所有主机SDN策略（例如在VFP中实现的策略）。如果没有其他机制，这些重要功能将无法执行，因为主机中的SDN协议栈无法处理数据包。
2.4通用流表卸载
AccelNet的目标之一是找到一种使VFP的复杂策略与SR-IOV兼容的方法。我们在VFP中使用的用于在SR-IOV环境中强制执行策略和过滤的机制称为通用流表（GFT）。GFT是一种匹配操作语言，它为一个特定的网络流定义了对数据包的转换和控制操作。从概念上讲，GFT由一个大表组成，该表具有一个主机上每个活动网络流的条目。GFT流是基于VFP统一流（UF）定义定义的，它匹配可能跨越多层封装的唯一的源L2 / L3 / L4元组和目标L2 / L3 / L4元组，以及标头转换（HT）操作，该操作指定标头字段的处理方式 添加/删除/更改。
只要GFT表不包含网络流条目（例如，当启动新的网络流时），就可以将流引导到主机上运行的VFP软件。然后，VFP使用实时流动作编译器为流的第一个数据包处理所有SDN规则，为每个UF（例如每个TCP / UDP流）创建有状态的精确匹配规则，并创建一个包含所有 该流程的已编程策略。然后，VFP会在GFT表中填充新条目，并将数据包交付进行处理。
在GFT表中填充了流操作后，随后的每个数据包将由GFT硬件进行处理，从而提供SR-IOV的性能优势，但对VFP的软件SDN协议栈具有完整的策略和过滤功能。
3 设计目标和原理
我们在2013-2014年定义了GFT模型，但是有很多选择可以跨硬件和软件构建完整的解决方案。在着手为主机SDN构建硬件卸载时，我们从以下目标和约束开始：
1.不要消耗主机CPU核资源
与竞争对手一样，Azure作为IaaS产品直接向客户出售VM，并以这些VM的价格进行竞争。我们在IaaS中的获利能力是客户为VM支付的价格与托管VM的成本之间的差。由于我们每台服务器的成本固定，因此降低VM成本的最佳方法是在每台主机服务器上打包更多VM。因此，大多数云通常会在给定的2插槽（经济和高性能标准）刀片的一代中合理地部署尽可能多的CPU内核。在撰写本文时，物理核心（2个超线程）的价格为$ 0.10-0.11 / hr（Azure D v3系列或AWS EC2 m4系列实例，价格因地区而异），或在服务器的整个生命周期内（服务器通常使用3到5年）的最大潜在收入为每年$ 900和$ 4500。在我们的数据中心）。即使考虑到某些内核随时都未售出，并且云通常会为客户提供一定的购买容量折扣，即使使用一个物理内核进行主机联网也比专用硬件昂贵。从根本上说，我们的业务依赖于每个主机向客户VM出售尽可能多的内核，因此，我们将竭尽全力以减少主机开销。因此，应避免使用主机CPU内核运行高速SDN数据路径。
2.维护VFP的主机SDN可编程性
VFP是高度可编程的，包括多控制器模型，状态流处理，用于大量规则的复杂匹配功能，复杂的规则处理和匹配操作以及轻松添加新规则的能力。如此高的可编程性是Azure能够为客户提供高度可配置且功能丰富的虚拟网络并随着时间的推移利用新的虚拟网络功能实现创新的能力的关键因素。我们不想牺牲这种可编程性和灵活性来提高SR-IOV的性能—实际上，我们希望SDN控制器在不知道卸载策略的情况下继续以VFP为目标。这还将在没有AccelNet必需硬件的主机服务器上保持兼容性。
将每条规则卸载到硬件上既不可行也不可取，因为这将约束SDN策略或要求每次创建新规则时都要更新硬件逻辑。但是，我们得出的结论是，无需卸载所有规则。大多数SDN策略在流程持续时间内不会更改。因此，可以在VFP软件中对新TCP / UDP流的第一个数据包强制实施所有策略，然后可以将该流的操作缓存为精确匹配查找。即使对于短流量，我们通常也会观察到至少7-10个数据包（包括握手），因此仅在软件中处理第一个数据包仍允许大部分数据包被卸载（如果卸载操作既快速又有效）。
3.实现SRIOV硬件的延迟，吞吐量和利用率
基本的SR-IOV NIC为硬件虚拟化的网络设置了可能的起点-完全绕过主机SDN协议栈和调度程序，以实现低（且一致）的延迟，高吞吐量和无主机CPU利用率。仅卸载精确匹配流以及相关联的操作，就可以进行易于处理的硬件设计，并在每个流的第一个数据包之外的所有数据包上充分发挥本机SR-IOV硬件解决方案的性能。
4.随着时间的推移，支持新的SDN工作负载和原语
VFP不断发展，支持新的要求和新的政策，AccelNet必须能够与VFP一起发展。我们曾经并且继续非常警惕那些将我们锁定在一组固定的流动动作中的设计。AccelNet不仅需要支持添加/更改操作，而且基础平台还应允许新的工作负载不能整齐地映射到单个完全匹配表。
5.向整个通道推出新功能
作为对先前要求的推论，AccelNet平台需要能够在现有硬件机群中而不是仅在新服务器上频繁部署新功能。客户不必将其现有部署迁移到新的VM类型即可启用新功能。同样，在各个硬件世代之间保持相同的SDN功能，使我们的开发，鉴定和部署更加容易。
6.提供高单连接性能
根据我们基于软件的SDN的经验，我们知道，单个CPU内核上的网络处理通常无法达到40Gb或更高的峰值带宽。将吞吐量扩展到一个内核可以处理的极限之外的一种好方法是利用多个线程将负载分散到多个内核，从而将单个连接拆分为多个并行连接。但是，将流量分布在多个连接上需要对客户应用程序进行实质性更改。即使对于实现多个连接的应用程序，我们也看到许多应用程序无法很好地扩展到许多流上，因为流通常是突发性的-应用程序会将大型消息转储到一个流上，而其他消息则保持空闲。
AccelNet的明确目标是允许应用程序实现近峰带宽，而无需并行处理其应用程序中的网络处理。
7.可以扩展到100GbE +
我们为2015年的服务器设计了AccelNet，该服务器将广泛部署40GbE。但是我们知道，在未来的几代人中，每台服务器的内核数量和网络带宽将继续增加，在不久的将来可能达到100GbE或更高的速度。我们希望SmartNIC设计能够随着网络速度和VM数量的增加而继续有效地扩展。
8.保持可维修性
VFP旨在在后台完全可维护，而不会丢失任何流状态，并支持通过迁移VM实时迁移所有流状态。我们希望我们的SmartNIC软件和硬件协议栈具有相同级别的可维护性。
4 SmartNIC硬件设计
4.1硬件选项
基于上述目标，我们着手评估SmartNIC体系结构的不同硬件设计。
传统上，Microsoft与网络ASIC供应商（例如Intel，Mellanox，Broadcom等）合作，在Windows中实现主机网络的卸载，例如1990年代的TCP校验和和分段卸载[9]，接收侧缩放（RSS）[10]和Virtual Machine Queues（VMQ）[11]在2000年代实现多核可伸缩性，最近在2010年代实现了用于Azure虚拟网络方案的NVGRE和VxLAN封装的无状态卸载[12]。实际上，GFT最初是由ASIC供应商设计为与SR-IOV配合使用的精确匹配表，并且我们在业界广泛分享了早期的设计思想，以了解供应商是否可以满足我们的要求。一段时间之后，由于没有新的设计能够满足第3节中列出的所有设计目标和约束，我们对这种方法的热情逐渐减弱。
SmartNIC供应商的一个主要问题是SRIOV是全有或全无的卸载示例。如果无法在SmartNIC中成功处理任何必需的SDN功能，则SDN协议栈必须恢复为通过基于软件的SDN协议栈发送回流，从而几乎失去了SR-IOV卸载的所有性能优势。
我们看到了四个不同的可能方向：ASIC，SoC，FPGA，以及对现有CPU的坚持。
4.1.1基于ASIC的NIC
用于SDN处理的定制ASIC设计可提供最高的性能潜力。但是，随着时间的流逝，它们缺乏可编程性和适应性。特别是，需求规范和芯片到货之间的时间跨度大约为1-2年，在此期间需求不断变化，使得新芯片已经落后于软件需求。ASIC设计必须在服务器的5年使用寿命中继续提供所有功能（在我们的规模上改造大多数服务器是不可行的）。Allornothing卸载意味着，今天制定的ASIC设计规范必须满足未来7年的所有SDN要求。
ASIC供应商通常会添加嵌入式CPU内核来处理新功能。与其他NIC处理硬件相比，这些内核可能很快成为性能瓶颈。此外，随着新功能的增加，随着时间的推移，这些核心将承担越来越大的处理负担，从而加剧了性能瓶颈。这些内核通常也通过对NIC进行固件更新来编程，这由ASIC供应商处理，并且减慢了新功能的部署。
4.1.2基于多核SoC的NIC
基于多核SoC的NIC使用大量嵌入式CPU内核来处理数据包，以某种性能进行交易以提供比ASIC设计更好的可编程性。这些设计在10GbE NIC一代中得到了广泛使用。有些像Cavium [13]使用通用CPU内核（MIPS，后来的ARM64），而另一些像Netronome [14]和Tilera则具有用于网络处理的特定内核。在这个领域中，我们更喜欢通用SoC，因为我们认为它们更易于编程（您可以采用标准的DPDK风格的代码并在熟悉的Linux环境中运行它）。令我们惊讶的是，与同类ASIC设计相比，它们在性能上没有太多缺点。
但是，在40GbE和更高的更高网络速度下，内核数会大大增加。用于分散和收集数据包的片上网络和调度程序变得越来越复杂且效率低下。我们经常看到与将数据包放入核心，处理数据包并返回到网络相关的10 us或更长时间的延迟-延迟比ASIC高得多，并且可变性也大得多。而且有状态流倾向于仅映射到一个内核/线程，以防止在单个流中发生状态共享和乱序处理。因此，由于嵌入式CPU不能以与网络带宽相同的速度提高性能，因此各个网络流性能不会得到很大改善。如第3节所述，这导致开发人员不得不将其流量分散在多个流中的问题，这将更快的网络的性能优势限制为仅最并行的工作负载。
SoC式网络卸载的未来也值得怀疑。在10GbE时，整个封装是可以容忍的，只有几个通用SoC内核就足够了。40GbE需要将近四倍的内核，尽管仍有多家供应商创建了可行的解决方案。尽管如此，具有基于软件的数据路径的40GbE部件已经非常庞大，耗电且昂贵，并且它们在100GbE，200GbE和400GbE方面的可扩展性看起来很暗淡。
注：图片来自Xilinx唐杰有关SmartNIC U25介绍PPT
因此，尽管我们发现SoC方法具有熟悉的编程模型的优势，但单流性能，较高的延迟以及较高的网络速度下可伸缩性较差，这使我们在寻找另一种解决方案。
4.1.3 FPGA
现场可编程门阵列（FPGA）是由小型通用逻辑块和存储器组成的可重新配置硬件设备，它们均由静态配置的网络连接。程序员编写代码，将通用逻辑和存储器组装到“软逻辑”电路中，形成定制的专用处理引擎，从而使ASIC的性能与SoC NIC的可编程性相平衡。
与基于SoC NIC上的CPU相比，FPGA仅用基本元素进行编程才能完成应用程序，甚至可以利用应用程序特性（例如数据的最大大小）来减少总线宽度和存储要求。有许多研究表明，在微处理器仿真[15]，基因组学[16]，机器学习[17]，联网，模式匹配，图形处理等广泛的应用空间中，FPGA可以比纯软件实现将应用程序加速几个数量级等等。
FPGA吸引AccelNet的关键特性是适应新功能的可编程性，定制硬件的性能和效率，以及创建深度处理管道的能力，从而改善了单流性能。
当我们评估SmartNIC选项时，微软已经完成了将FPGA部署为Catapult项目[7]的数据中心加速器的工作-我们成功地建立了成千上万个联网的FPGA节点集群，对Bing进行了搜索排名，从而极大地提高了性能并降低了其性能。成本，并且网络传输层在机架内的FPGA之间运行。这使我们相信，FPGA可能是SmartNIC的可行选择，因为它们有可能解决我们希望获得ASIC性能特征的难题，但需要像SoC这样的软件解决方案固有的可编程性和可重新配置性。
4.1.4消耗主机核资源
我们仍然对照我们最初的策略，即只使用主机内核来运行我们的SDN协议栈，尤其是像DPDK[18]这样的技术表明，我们可以通过绕过操作系统网络协议栈，在轮询模式下运行内核来显著降低数据包处理的成本。鉴于我们无法让ASIC满足我们的可编程性要求，这个方案击败了ASIC，但消耗内核的成本和性能开销对我们的虚拟机托管成本的影响足够大，如第3节所述，即使是低效率的多核SoC也是一个更好的方法。
4.2 评估FPGA作为SmartNICs的应用场景
从我们的最初分析看，FPGA似乎是一个不错的选择，但是直到那时，我们完全由软件部门运营的主机网络组最初还是持怀疑态度的-尽管FPGA被广泛用于路由器，蜂窝应用和设备的网络中，通常不用作NIC或数据中心服务器，并且该团队没有在生产环境中编程或使用FPGA的丰富经验。在我们决定走这条路之前，必须回答以下一些问题：
1. FPGA是否比ASIC大得多？
FPGA的通用逻辑部分大约比ASIC中的相同逻辑大10-20倍，因为使用可编程存储器(查找表，或LUT)代替了门，并且使用可编程的线和复用器网络代替专用线将元件连接在一起。如果FPGA设计仅仅是通用逻辑，我们应该期望需要比ASIC多10-20倍的硅面积。然而，FPGA有许多硬化块，如嵌入式SRAM、收发器和I/O协议块等，所有这些都是定制组件，几乎与定制ASIC中的定制组件相同。
从现代NIC来看，数据包处理逻辑通常不是最大的部分。相反，大小通常由SRAM存储器（例如，用于保存流上下文和数据包缓冲区），支持I / O的收发器（40GbE，50GbE，PCIe Gen3）和驱动这些接口的逻辑（用于以太网的MAC + PCS，PCIe控制器，DRAM控制器）控制，所有这些在FPGA上也可以是硬逻辑。此外，现代ASIC设计通常包括大量额外的逻辑和可配置性（甚至是嵌入式CPU内核），以适应来自不同客户的不同要求。需要这种额外的逻辑来最大化容量，处理不断变化的需求并解决不可避免的错误。先前的工作表明，这种可配置性可以为ASIC逻辑增加一个数量级的面积[19]。因此，FPGA包含越来越多的自定义逻辑的趋势，而ASIC包含越来越多的可编程逻辑的趋势，缩小了这两种选择之间的效率差距。
实际上，我们认为，对于这些应用，FPGA的容量应比类似功能的ASIC大2-3倍，对于大规模提高可编程性和可配置性，我们认为这是合理的。
2. FPGA不是很贵吗？
尽管我们无法公开披露供应商的价格，但FPGA市场竞争激烈（有2个实力雄厚的供应商），而且我们能够大规模采购。根据我们的经验，我们的规模可以摊销不可回收的工程成本，并且硅的成本由硅面积和成品率决定。服务器中的总硅片面积通常受CPU，闪存和DRAM的支配，由于FPGA的规则结构，其产量通常很好。
3. FPGA难于编程吗？
这个问题是主机网络团队最怀疑的根源，他们当时不在数字逻辑设计或Verilog编程领域。与可编程逻辑CPU相比，FPGA可以提供令人难以置信的性能，但前提是硬件设计人员必须真正考虑应用的高效流水线设计并对其进行布局。该项目最初由Microsoft Research的Catapult团队协助，但最终我们在Azure Networking for SmartNIC中建立了自己的FPGA团队。该团队比典型的ASIC设计团队要小得多，AccelNet团队在任何给定时间平均只有不到5个FPGA开发人员参与该项目。
我们在AccelNet上的经验以及微软内部的其他项目，如用于网络搜索的Bing Ranking [7，8]，用于数据压缩的LZ77 [20]，以及用于机器学习的Brain Wave [17]，都证明了FPGA的编程对于生产规模的云工作负载是非常容易操作的。这四种应用都使用了完全相同的硬件，这表明Azure SmartNIC的可编程性和灵活性远远超出了SDN和网络处理能力。这预示着我们将在未来几年内努力增加新的功能。在强大的开发团队、基础设施、仿真能力和工具方面的投资是必不可少的，但其中的很多内容可以在不同团队之间共享。
我们发现，FPGA成功编程的最重要的因素是让硬件和软件团队在一个小组中一起工作，并使用软件开发方法（如敏捷开发）而不是硬件（如瀑布式）模式。FPGA的灵活性使我们能够以比其他任何类型的硬件设计都要快得多的时间间隔进行编码、部署、学习和修改。这种硬件/软件的编码模式，使硬件的性能与软件的灵活性相得益彰。
4. FPGA是否可以超大规模部署？
让FPGA进入我们的数据中心并不是一件容易的事--当项目Catapult开始时，这并不是FPGA的常见用例，团队必须在以下几个方面下功夫：遇到了许多技术、物流和团队结构的问题。然而，在我们开始SmartNIC的时候，Catapult已经解决了许多超大规模部署所需的通用基础设施细节。Catapult shell和相关的软件库将底层的硬件细节抽象化，使SmartNIC的硬件和软件开发主要集中在应用功能上。尽管这些功能现在对FPGA厂商来说已经很普遍，但在当时并不支持。如果没有Catapult之前的工作，这个项目是不可能实现的。
5. 我的代码不是锁定在单一的FPGA厂商吗？
现在的FPGA开发几乎都是用SystemVerilog这样的硬件描述语言来完成的（我们用的是SystemVerilog），如果最初开发的时候是为了方便移植，那么这些语言是可以移植的。这里面有厂商的具体细节，例如Intel FPGA有40b宽的SRAM，而Xilinx的SRAM是36b，但一旦考虑到这些细节，编译不同的FPGA的代码并不难。作为可移植性的一个证明点，项目Catapult最初是在Xilinx FPGA上开发的，但在我们最初的试点之前就被移植到了Altera FPGA上。
4.3 SmartNIC系统架构
即使在选择了FPGA作为前进的道路之后，仍然存在着如何集成的重大问题--FPGA应该在我们的第一个SmartNIC的系统架构中的位置，以及它应该包括哪些功能？最初的Catapult FPGA加速器[7]故意不连接到数据中心的网络上，以避免成为一个可能导致服务器瘫痪的组件，而是通过机架内的后端Torus网络连接。这并不适合用于SDN offload，因为FPGA需要在网络路径上实现VFP功能。
另一种选择是在FPGA内部构建一个完整的NIC，包括SRIOV，但这是一项艰巨的任务（包括将驱动程序放入我们所有的VM SKU中），并且将要求我们实现当前已部署的NIC处理的无关功能，例如RDMA [14]。相反，我们决定通过FPGA扩展当前的NIC功能，并最初将FPGA开发的重点仅放在SDN卸载所需的功能上。
融合架构使FPGA成为NIC和机架顶部（TOR）交换机之间的直接连接，使FPGA成为网络上的过滤器。一根电缆将NIC连接到FPGA，另一根电缆将FPGA连接到TOR。FPGA还通过2个Gen3x8 PCIe连接连接到CPU，对于加速器工作负载（如AI和Web搜索）很有用。当用作加速器时，网络连接（以及使用DCQCN [21]的类似RDMA的无损传输层）可以扩展到诸如大型DNN模型之类的工作负载，而这些模型无法安装在一个芯片上。最终的第一代Azure SmartNIC从2015年开始部署在所有Azure计算服务器中，如图2（a）所示。
图2：Azure SmartNIC板与Bump-in-the-Wire架构的Azure SmartNIC板
运行在50GbE的第二代SmartNIC（图2（b））是为Azure Project Olympus OCP服务器设计的[22]。我们将标准NIC和SRIOV集成在与FPGA相同的板上，以保持相同的线内即插即用架构，但是省去了单独的NIC板以及NIC和FPGA之间的电缆，从而降低了成本，并升级到了较新的Intel Arria 10 FPGA。
5 AccelNet系统设计
AccelNet的控制平面与[6]中的原始VFP设计没有太大变化，并且几乎完全保留在虚拟机监控程序中。它仍然负责从流表中创建和删除流，以及确定每个流的关联策略。AccelNet的数据平面已卸载到FPGA SmartNIC。NIC的驱动程序增加了称为GFT轻型过滤器（LWF）的过滤器驱动程序，该驱动程序从VFP中提取了分离的NIC / FPGA硬件的详细信息，以使SmartNIC看起来像是具有完整SR-IOV和GFT的单个NIC。7.1节中详细讨论的支持和帮助提高可维护性。
5.1软件设计
虽然GFT的绝大部分数据包处理工作落在FPGA硬件上，但软件仍然负责控制操作，包括流量的设置/卸载、健康监测和启用服务性，以便在更新到虚拟机和FPGA硬件期间，流量可以继续进行。我们架构的高阶视图如图3所示。流量表可能不包含一个给定数据包的匹配规则。在这种情况下，卸载硬件将把数据包作为异常包发送到软件层。异常数据包最常见于网络流的第一个数据包上，当网络流刚刚建立时。
为hypervisor建立一个专用于hypervisor的特殊虚拟端口(vPort)，用于异常数据包。当FPGA接收到一个异常数据包时，它会在数据包中超载802.1Q VLAN ID标签，以指定它是一个异常路径数据包，并将该数据包转发到hypervisor vPort。VFP监控这个端口，并在确定了数据包的适当流量策略后，执行必要的流量创建任务。如果异常数据包的目的地是同一主机上的虚拟机，VFP软件可以直接将该数据包传送到虚拟机上。如果异常数据包是向外发送的（由虚拟机发送的是远程服务器），那么VFP软件必须将数据包重发到SmartNIC，它可以使用相同的专用管理程序vPort来完成。
图3：SmartNIC GFT体系结构，显示了异常数据包从FPGA到软件建立异常数据包在硬件中卸载的流程
VFP还需要知道终止的连接，以便旧的连接规则与新的网络流不匹配。当FPGA检测到终止数据包（例如设置了SYN，RST或FIN标志的TCP数据包）时，它将复制该数据包-将原始数据包发送到其指定的目的地，并将该数据包的相同副本发送到专用虚拟机管理程序vPort。VFP使用此数据包跟踪TCP状态并从流表中删除规则。
5.2 FPGA流水线设计
GFT数据路径设计在4.3中描述的Azure SmartNIC硬件上实现。在本节的其余部分中，我们重点介绍在SmartNIC Gen1上的实现，尽管相同的结构（具有不同的值）适用于Gen2。
FPGA上GFT实现的设计可以分为2个深层流水线的数据包处理单元，每个单元包括四个主要的流水线阶段：（1）存储和转发数据包缓冲区，（2）解析器，（3）流查找以及 匹配，以及（4）流动作。图4显示了我们的系统架构的高级视图。
图4：GFT处理流水线的方框图
解析器阶段解析来自每个数据包的聚合头信息以确定其封装类型。目前，我们支持解析和处理多达3组L2/L3/L4报头（共9个报头，310个可能的组合）。解析器的输出是一个对每个网络流唯一的密钥。
第三个处理阶段是Matching，根据Parser阶段的唯一密钥查找数据包的规则。Matching计算出密钥的Toeplitz散列[23]，并将其作为缓存索引。我们采用2级缓存系统，其中L1缓存存储在片上，L1缓存存储在片上，L2缓存存储在FPGA连接的私有DRAM中。
L1缓存的结构为直接映射缓存，支持2048个流量。我们用2路集关联缓存和比Toeplitz散列算法更简单的散列算法进行了实验[24]，但发现更多的计算密集型的Toeplitz散列与更简单的直接映射缓存结合起来，可以获得更好的整体性能。
L2缓存的结构为8路集关联缓存，并支持O（1M）流。支持的流总数仅受DRAM容量的限制。
最后一个组件是Action阶段，它从流量表中提取查询到的参数，然后在数据包头上执行指定的变换。Action 块使用微代码来指定动作的确切行为，这样就可以在不重新编译FPGA映像的情况下轻松地更新动作。只有当添加全新的动作时，才需要重新编译FPGA并加载一个新的bit流。
非琐碎的软件可编程服务质量保证可以作为处理流水线的可选组件来实现。例如，速率限制可以使用DRAM中的数据包缓冲器在每个流量的基础上进行。关于我们的QoS框架和行动的完整描述超出了本文的范围。总的来说，GFT角色使用了我们在Gen1 SmartNICs中使用的Intel Stratix V D5芯片的1/3左右的逻辑资源。
5.3 流量跟踪和调节
VFP被上层控制器和监控层用于跟踪每流连接状态和数据。GFT 追踪所有的每连接字节/流计数器，如 TCP 序列/ACK 号和连接状态，以及流最后一次收到数据包的时间戳。它定期通过PCIe通过DMA传输将所有流状态传输到VFP，使VFP能够确保正确的流配置，并执行诸如清理非活动流等操作。
GFT还必须执行对帐，以便在VFP策略更改时更新流操作。像VFP的统一流表一样，GFT维护系统上策略状态的世代ID，并在创建每个流的规则时跟踪世代ID。当控制器将新策略应用于VFP时，SmartNIC上的世代ID会增加。然后，通过将每个流的第一个数据包标记为异常数据包，并让VFP使用新的策略操作更新该数据流，来延迟更新数据流。
6 性能结果
自2016年以来，Azure加速网络已可用。性能结果是在Azure数据中心中的正常Azure AccelNet VM上测得的，该VM在运行40Gbps Gen1 SmartNIC的Intel Xeon E5-2673 v4（Broadwell，2.3 GHz）上运行。发送方和接收方VM处于同一数据中心，并且跨5个标准交换ASIC之间的Clos网络。我们没有创建任何特殊配置，并且图5中的结果应可由使用大型Dv2或Dv3系列Azure VM的任何Azure客户复制。应用于这些VM的VFP策略包括网络虚拟化，有状态NAT和有状态ACL，计量，QoS等。
图 5：来自 Azure AccelNet VM 的精选性能数据
我们使用注册的I/O套接字[25]，通过在活动的TCP连接上依次发送100万个4字节的ping并测量响应时间，来测量两个Windows Server 2016虚拟机之间的单向延迟。在不使用AccelNet的情况下，我们的调优软件栈，我们看到的平均延迟为50us，其中P99约为100us，P99.9约为300us。使用AccelNet，我们的平均时间是17us，P99为25us，P99.9为80us--延迟和抖动都要低很多。
Azure提供的VM大小具有高达32Gbps的网络容量。通过将对TCP拥塞控制设置为CUBIC [26]和1500 Byte MTU的Ubuntu 16.04 VM和Windows 10 VM配对，我们可以在主机之间具有0％关联CPU利用率的VM之间的单个连接上持续测量31Gbps。如果没有AccelNet，我们将在单个连接上看到5Gbps的速度，并在主机中使用多个内核，并且运行足够的连接（8）以实现线速。由于我们不必跨多个核心进行扩展，因此我们相信，随着我们通过越来越大的VM继续提高网络速度，可以使用当前的体系结构将单个连接性能扩展到50 / 100Gb线速。
对于一个实际应用的例子，我们将 AccelNet 部署到我们的 Azure SQL DB 团队中，该团队在 VM 实例中运行，并从同一 DC 中的 AccelNet 虚拟机针对跨多个节点复制的内存内 DB 运行 SQL 查询，以实现高可用性（对服务的读和写都要穿越多个网络跳转）。平均端到端读取时间从约1ms到300us，并且 P99的读和写时间因此下降了一半以上 减少网络中的抖动。复制和播种往往受制于突发事件的表现的工作 单个连接上运行速度超过2倍。
图6：AccelNet VM-VM延迟与Amazon AWS Enhanced Networking和Google GCP Andromeda在英特尔Skylake一代硬件上的性能对比。
图6显示了AccelNet与我们在最新一代基于Intel Skylake的实例（Azure上的Fs72 v2，AWS上的c5.18xlarge，GCP上的n1-highcpu-64，在2017年11月测得）上比较的其他公共云产品的比较性能。所有测试都使用平台提供的未修改的Ubuntu 16.04映像，并且启用了忙轮询。我们使用开源工具sockperf和iperf分别测量延迟和吞吐量。在我们的测量中，AccelNet在我们测量的实例中具有最低的延迟，最高的吞吐量和最低的尾部延迟（以在已建立的TCP连接上连续10多次连续乒乓运行的所有ping的百分位数衡量）。我们的Linux VM之间的平均延迟。为了测试诸如DPDK之类的用户空间I / O的性能，我们使用了基于开源VMA库[27]的用户空间TCP协议栈，该协议栈在我们的生产VM之间对标准TCP套接字执行ping操作约有5微秒的延迟。
VFP在我们的机群中被广泛用于运行我们的SDN和外部网络之间的软件网关桥接，如ExpressRoute[28]电路到客户的数据交换机。我们在FPGA GFT实现中使用了可编程转发和QoS，将所有的转发（流中的第一个数据包之后）卸载到SmartNIC。包括encap/decap、有状态的ACLs/NAT和计量、QoS和转发，我们看到一个网关转发的线速为32Gbps的流量（即使只有一个流量），并且在主机CPU利用率为0%的情况下，延迟一致<5s。我们之前的网关转发需要多次连接才能达到线速，消耗CPU核心，并且根据系统调度行为，延迟可能会飙升到100-200µs（包括往返于虚拟机之间）。我们相信这个平台将让我们创造出更多加速的可编程设备。
我们在SmartNIC上使用可配置的电源调节器，我们测量了Gen1板的功耗，包括运行中的服务器中所有组件的功耗为17-19W，这取决于流量负载。这远远低于典型的PCIe扩展槽所允许的25W功率，与我们所见过的其他SmartNIC设计相当，甚至更低。
7 业务化
7.1 服务性
与任何其他为公共云构建的功能一样，可服务性、诊断和监控是加速网络的关键方面。事实上，软件和硬件都是可服务的，这就使得我们可以在这个主要的场景中进行部署。正如[6]中所讨论的那样，VFP在保持现有的TCP连接的同时，已经完全可服务，并且支持虚拟机与现有连接的实时迁移。通过AccelNet，我们需要扩展这种可服务性--TCP流和vNICs应能在FPGA重新配置、FPGA驱动更新、NIC PF驱动更新（会降低VFs）和GFT驱动更新的情况下运行。
我们通过关闭硬件加速并切换回合成vNIC来完成在线服务性，当我们想为SmartNIC或驱动SmartNIC的软件组件提供服务时，或者是实时迁移VM时，我们可以通过关闭硬件加速并切换回合成vNIC来保持连接性。然而，由于AccelNet是以VF的形式直接暴露在VM中，因此我们必须确保当VF被撤销并将数据路径切换到合成模式时，没有一个应用程序中断。为了满足这个要求，我们不直接将VF暴露到VM中的上层协议栈中。相反，当VF出现时，我们的合成网卡驱动--Hyper-V网络虚拟服务消费者(NetVSC)，通过使用Linux虚拟机内核中存在的从属模式，或者通过绑定到Windows虚拟机中的NetVSC的上层NDIS边缘，将VF标记为它的从属模式。我们称之为透明绑定--TCP/IP栈只绑定到合成网卡。当VF活动时，合成适配器会自动在VF适配器上发出发送，而不是通过合成路径发送到主机。对于接收，合成适配器会将来自VF和合成路径的所有接收到的数据都向上转发到栈中。当VF被撤销服务时，所有的传输流量自动切换到合成路径，而上层栈甚至不知道VF被撤销或以后的重新分配。图7所示为加速数据路径和合成数据路径。由于NetVSC提供了透明绑定，所以网络栈对当前数据路径完全透明。
图7：SR-IOV接口和合成接口之间的透明绑定
SR-IOV的优点之一是，VM可以使用内核旁路技术，例如DPDK（数据平面开发套件）[18]或RDMA（远程直接内存访问），通过VF直接与硬件接口， 但是当撤销VF时，我们也需要考虑它们的可服务性，并且VM可能会实时迁移到其他地方。我们需要这些应用程序在那个短暂的时间内透明地退回到非加速的代码路径。
我们发现，许多DPDK应用没有内置的回退机制。因此，我们使用了一个故障安全PMD（Poll Mode Driver），它作为VF PMD和合成接口上的一个PMD之间的纽带。当VF被激活时，故障安全PMD在VF PMD之上运行，从而绕过VM内核和主机软件栈。当VF因可服务性而被撤销时，故障安全PMD开始在合成路径上运行，数据包通过VMBUS通道流过。由于故障安全机制 PMD暴露了所有的DPDK API，除了短时间内性能下降外，应用程序看不到任何区别。
对于RDMA应用程序，这种可维护性形式更加困难，并且可能涉及更多队列。在实践中，我们发现所有常见的RDMA应用程序都经过了精心设计，可以正常地退回到TCP，因此我们通过发布完成来关闭所有RDMA队列对，并让该应用程序故障转移到TCP。对于当前已知的工作负载而言，这不是问题，但是如果应用程序对RDMA QP的持久依赖，则应用程序级的RDMA可维护性透明性仍是未来的未解决问题。
对透明VF绑定的支持已在Linux内核的上游（对于NetVSC）和对dpdk.org的DPDK进行了承诺，并且在Windows Server 2012和更高版本的VM中具有本地可用。我们已对AccelNet协议栈的所有部分（通过GFT的VFP，FPGA和PF驱动程序）发布了定期的全机范围更新，并发现透明绑定对于我们的客户实际上是行之有效的。虽然在合成路径处于活动状态时性能会短暂下降，但应用程序仍然处于活动状态并可以很好地处理此问题，因为它们看不到绑定到的网络适配器或活动的TCP连接上的更改。如果应用程序对此敏感，我们让VM订阅实例元数据服务，该实例元数据服务向VM发送有关即将进行的维护和更新事件的通知，以使其能够在其他地方准备或转移流量。如果VM在Azure负载平衡器后面运行，我们可以在更新期间将其从活动的负载平衡集中删除，以便在更新窗口期间将新的外部TCP / UDP流定向到其他位置。
7.2监控和诊断
监视对于诸如AccelNet之类的系统的可靠性至关重要。为了获得生产质量的可靠性，必须从硬件和软件中检测预警信号并以自动方式进行纠正。我们从AccelNet的每个组件中收集指标，包括VFP，GFT，SmartNIC及其驱动程序以及SR-IOV NIC及其驱动程序-我们在可扩展性中为每个主机收集了500多个指标（其中每个按VM收集） 中央监控系统。警报和措施是由这些措施的组合触发的，随着我们在系统中获得越来越多的经验和数据，我们会不断调整阈值和措施。
为了进行诊断，我们在SmartNIC的每个接口上构建了可编程的数据包捕获和跟踪服务-数据包头和数据可以在入口/出口的NIC / ToR端口上采样。我们沿SmartNIC内部的网络总线构建了一个元数据接口，以便任何模块都可以发出有关该模块中数据包到底发生了什么的诊断数据，该数据包括在捕获中。例如，在GFT中，我们可以跟踪数据包的解析方式，匹配的流量，所采取的操作等。我们可以为这些数据收集硬件时间戳，以进行准确的延迟分析。我们还将在关键状态机以及大量计数器上公开诊断信息，并在出现错误时自动转储所有关键内部状态。
8 经验
Azure SmartNIC和AccelNet已大规模部署多年，在我们的机队中拥有成千上万的客户VM。根据我们的经验，AccelNet为我们的客户提供了全面的网络性能，而不会对可靠性或可维护性产生负面影响，并且提供了比我们在公共云中衡量的任何其他结果更好的吞吐量和延迟。我们相信我们的设计可以实现我们在第3节中设定的所有目标：
- 我们停止消耗CPU内核来运行AccelNet VM的网络数据路径。主机内核显示用于异常处理的利用率不到1％。
- SDN控制器继续在VFP中添加新策略并对其进行编程，而与下面的硬件卸载无关。
- 与仅使用SR-IOV NIC相比，我们将FPGA的延迟开销测量为<1us，并实现了线速。这比单独使用CPU内核要好得多。
- 我们继续在FPGA上的GFT中添加新的操作和原语，以支持新的工作负载以及新的QoS原语等等。
- 更改已在多种类型的服务器和SmartNIC硬件上推出。
- 我们可以在单个连接上实现线路速率。
- 我们相信我们的设计可以很好地扩展到100Gb +。
- 多年来，我们已经定期对FPGA映像和驱动程序进行生产服务，而不会对VM或应用程序产生负面影响。
8.1 FPGA是否为数据中心准备好了？
我们经常被问到的一个问题是，FPGA是否准备好在Microsoft之外更广泛地用作SmartNIC。我们当然不能断言FPGA始终是在所有云环境中加速联网的最佳且唯一的解决方案。FPGA编程的开发工作肯定比软件要多，尽管可以通过一支有才华的硬件团队和多个利益相关者的支持来使处理工作变得相当灵活。
微软启动Catapult时，FPGA还远远没有做好云计算的准备。由于SmartNIC与Catapult共享共同的开发环境和历史，因此许多开发工作在团队之间共享。我们发现，在过去的几年中，必要的工具，基本的IP块和一般支持得到了显着改善。但这对于新团队来说仍然是艰巨的任务。我们没有发现我们尝试过的FPGA高级语言能够为我们的设计产生有效的结果，但是我们训练有素的硬件开发人员可以快速迭代SystemVerilog代码，没有任何麻烦。
Azure的规模足够大，足以证明我们的开发努力是合理的--我们实现了CPU不可能达到的性能和效率水平，可编程性远超ASIC，而且由于我们的产量，成本也是合理的。但是，在生态系统进一步发展之前，我们认为这不会成为大规模云计算供应商以外的人的自然选择。
8.2 变化
正如我们所期望的，随着SDN协议栈的发展，我们会随着时间的推移继续添加各种操作，而这些操作是我们启动时无法预料的，例如新的有状态隧道模式和状态跟踪。我们相信，对这些快速变化的要求做出响应在ASIC开发流程中是行不通的。一小部分示例包括：
- 我们反复扩展了我们的TCP状态机，对系统中的每一个TCP流进行更精确的seq/ack跟踪，用于各种功能和诊断目的。例如，根据空闲超时和其他参数向活动流注入TCP重置的要求，使得VFP必须知道每个流的最新有效序列号。
- 我们创建了许多新的数据包转发和应用操作，例如支持具有自己的ncapsulation和SDN策略的分接接口，以及复杂的转发操作，以满足用户的需求。将网关和软件路由器卸载到硬件上，并在单播底层上使用快速硬件复制进行组播。
- 我们为内部工作负载添加了SDN操作，例如带有自定义转换逻辑的NAT46，对RDMA虚拟化的支持以及新的覆盖头格式。
- 当我们看到改善连接建立性能的压力时，我们反复在卸载路径上进行了迭代，根据生产遥测，随着时间的推移，将诸如散列和表插入流之类的许多功能从软件迁移到硬件。
- 我们用FPGA以线速增加了不断的新的数据路径诊断，包括可编程的数据包捕获，通过FPGA中的流水级进行数据包跟踪，进行延迟和正确性分析，以及大量的计数器和遥测，这些都需要在数据路径中的硬件支持的那种计数器和遥测。这是我们最不变的迭代来源。
8.3 经验教训
自从开始Azure加速网络项目以来，我们学到了许多其他有价值的教训。
- 前期的服务性设计。第7节中的主题是这里最难做到的。它们之所以能够成功，是因为整个系统，从硬件到软件到虚拟机集成，从第一天起就被设计成可维护和可监控。可维护性是不可能事后才有的。
- 使用统一的开发团队。如果你希望硬件/软件共同设计，硬件开发人员应该和软件开发人员在同一个团队中。我们明确地将硬件团队建立在现有的Azure主机网络组内部，而不是传统的HW和SW组分开的方法，以鼓励频繁的协作和知识共享。
- 使用FPGA的软件开发技术。帮助我们提高敏捷性的一件事是将主机网络数据路径栈视为一个单一的栈，并跨VFP和FPGA的出货载体，减少了复杂的推出依赖性和计划错配。我们尽可能地把硬件逻辑当作软件来处理和发货。通过软件鉴定的迭代环，意味着我们不需要ASIC级别的规范和验证，我们可以更加敏捷。在现场环境中几分钟的时间，比一般的RTL验证流程所能涵盖的时间和场景要多得多。
- 更高的质量意味着更好的可靠性。AccelNet 对于虚拟机的最大好处之一是，网络数据路径不再与主机的其他部分共享核心或资源，而且不受瞬时问题的影响--我们已经看到了更可靠的性能和更低的抖动。
- HW/SW共同设计在迭代时是最好的。传统上，ASIC的开发意味着要为系统在其生命周期内可能要做的所有事情设计一个规范和测试方法。而FPGA让我们的硬件开发人员的方法更加灵活。我们可以直接向客户部署设计，从真实的工作负载中收集详细的计数器数据，并利用这些数据来决定下一个版本的硬件与软件中应该有哪些功能，以及性能瓶颈在哪里。更重要的是，我们可以让规范在整个开发过程中不断地演进。例如，我们在最初发布后，多次改变了散列和缓存策略。
- 故障率仍然很低，与系统中的其他无源器件一致，故障率最高的是DRAM。总的来说，FPGA在全球范围内的数据中心都是可靠的。
- 上层应与卸载无关。因为VFP从控制器和上层抽象出了是否正在执行SDN策略，所以AccelNet的部署中断性要小得多。
- 减轻Spectre的性能影响。在我们的CPU受到Meltdown和Spectre攻击之后，基于CPU的I/O受到了常见的缓解措施的影响[29]。由于AccelNet完全绕过了主机和CPU，因此我们的AccelNet客户看到对网络性能的影响明显较小，许多客户将旧的租户重新部署到支持AccelNet的硬件上，只是为了避免这些影响。
9 相关工作
自从我们首次部署了Azure SmartNIC并在2015年的开放网络峰会上宣布了它们之后，我们看到无数不同的带vSwitch offload的可编程网卡解决方案出现在市场上（最近，其中很多也被贴上了 "智能网卡 "的标签）。大多数遵循了我们在4.1中讨论的趋势。有些[30]是基于带有内部匹配-动作表的ASIC---这些方案往往不是很灵活，也不支持我们在GFT中随着时间的推移而实现的一些更高级的动作，并且随着动作和策略的变化，给了很少的增长空间。其他人[13，14]完全在嵌入式核心中做数据路径处理，无论是通用CPU还是网络专用的核心，但我们发现这种模式的性能并不是很好，我们没有看到在不需要很多核心的情况下将其扩展到100G以上的路径。一个较新的趋势是将支持某些匹配动作功能的ASIC与支持DPDK式数据路径的小型SoC结合在一起，用于核心上的数据包处理。但我们认为这并不能最终解决ASIC与CPU的两难问题--如果你有一个应用广泛的动作，而ASIC无法处理，那么你必须把所有的数据包都送到CPU上，而现在CPU必须处理线速处理。
其他人[31]表明，他们可以完全在主机中提高软件协议栈的性能，并建议消耗核心来做主机SDN。虽然我们认为这在实际应用中需要多个核心以线速来完成我们的工作负载，但在IaaS中，即使是采取极少量的核心，对我们来说成本太高，性能和延迟也不是最优的。通过FPGA，我们发现我们在实践中能够实现足够的可编程性和敏捷性。我们还探索了像[32]那样将功能卸载到交换机上，但由于我们必须为系统中的每一个TCP连接存储复杂的操作，而且随着节点上虚拟机和容器密度的增加，我们发现需要卸载的最小策略集，即使在合理压缩的情况下，也至少比最新的可编程交换机ASIC在SRAM中存储的策略集要多2个数量级--在网卡速度下，我们可以扩展到GB的DRAM。
最近的另一个建议是使用P4引擎[33]来创建智能网卡，到目前为止，P4引擎大多在交换机中实现。P4规范提供了灵活的解析和相对灵活的操作，其中许多操作类似于GFT。事实上，P4可以作为一种潜在的方式来指定一些GFT的处理流程。然而，在现有的P4引擎甚至P4语言规范的范围之外，还有一些其他SDN功能对我们在AccelNet中实现非常重要--比如调度、QoS、后台状态更新、任何类型的可编程传输层，以及简单的数据包变换范围之外的各种复杂策略。虽然我们期望P4语言可以扩展到包括其中的许多功能，但考虑到SDN和云空间不断发展的特性，使用FPGA等可编程架构来实现GFT或P4功能仍然是一个不错的选择。我们预计核心分组处理器之外的许多功能会随着时间的推移而变硬，但预计SDN在可预见的未来仍将是软性的。
10 结论与未来工作
我们详细介绍了Azure SmartNIC（我们基于FPGA的可编程网卡）和加速网络（我们的高性能网络服务，提供领先于云计算的网络性能），并介绍了我们构建和部署它们的经验。
本文主要描述了我们在主机SDN中已经在软件中完成的功能，并将其卸载到硬件上，以获得良好的性能。未来的工作将描述我们发现的全新的功能，我们发现现在每个主机上都有可编程的网卡，我们可以支持全新的功能。
参考文献
[1] Microsoft Azure. http://azure.microsoft.com, 2018.
[2] Amazon. Amazon Web Services. http://aws.amazon.com, 2018.
[3] Google. Google Cloud Platform. http://cloud.google.com, 2018.
[4] Microsoft. Overview of Single Root I/O Virtualization (SR-IOV). https://msdn.microsoft.com/enus/windows/hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-, Apr2017.
[5] Y. Dong, X. Yang, X. Li, J. Li, K. Tian, and H. Guan. High performance network virtualization with sr-iov. In HPCA – 16 2010 The Sixteenth International Symposium on High-Performance Computer Architecture, pages 1–10, Jan 2010.
[6] Daniel Firestone. VFP: A virtual switch platform for host SDN in the public cloud. In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), pages 315–328, Boston, MA, 2017. USENIX Association.
[7] Andrew Putnam, Adrian M. Caulfield, Eric S. Chung, Derek Chiou, Kypros Constantinides, John Demme, Hadi Esmaeilzadeh, Jeremy Fowers, Jan Gray, Michael Haselman, Scott Hauck, Stephen Heil, Amir Hormati, Joo-Young Kim, Sitaram Lanka, James R. Larus, Eric Peterson, Gopi Prashanth, Aaron Smith, Jason Thong, Phillip Yi Xiao, and Doug Burger. A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services. In International Symposium on Computer Architecture (ISCA), 2014.
[8] A. M. Caulfield, E. S. Chung, A. Putnam, H. Angepat, J. Fowers, M. Haselman, S. Heil, M. Humphrey, P. Kaur, J. Y. Kim, D. Lo, T. Massengill, K. Ovtcharov, M. Papamichael, L.Woods, S. Lanka, D. Chiou, and D. Burger. A cloud-scale acceleration architecture. In 2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 1–13, Oct 2016.
[9] Microsoft. TCP/IP Offload. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/tcp-ip-offload, Apr 2017.
[10] Microsoft. Introduction to Receive Side Scaling. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling, Apr 2017.
[11] Microsoft. Virtual Machine Queue (VMQ). https://msdn.microsoft.com/en-us/windows/hardware/drivers/network/virtual-machine-queue--vmq-, Apr2017.
[12] Microsoft. Network Virtualization using Generic Routing Encapsulation (NVGRE) Task Offload. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/network-virtualization-using-generic-routing-encapsulation--nvgre--task-offload, Apr 2017.
[13] Cavium. Cavium LiquidIO II Network Appliance Smart NICs. http://www.cavium.com/LiquidIO-II_Network_Appliance_Adapters.html.
[14] Netronome. Open vSwitch Offload and Acceleration with Agilio CX SmartNICs. https://www.netronome.com/media/redactor_files/WP_OVS_Benchmarking.pdf.
[15] Derek Chiou, Dam Sunwoo, Joonsoo Kim, Nikhil A. Patil,William Reinhart, Darrel Eric Johnson, Jebediah Keefe, and Hari Angepat. Fpga-accelerated simulation technologies (fast): Fast, full-system, cycle-accurate simulators. In Proceedings of the 40th Annual IEEE/ACM International Symposium on Microarchitecture, MICRO40, pages 249–261, Washington, DC, USA, 2007. IEEE Computer Society.
[16] Yatish Turakhia, Kevin Jie Zheng, Gill Bejerano, and William J. Dally. Darwin: A hardware-acceleration framework for genomic sequence alignment. bioRxiv, 2017.
[17] Eric Chung, Jeremy Fowers, Kalin Ovtcharov, Michael Papamichael, Adrian Caulfield, Todd Massengil, Ming Liu, Daniel Lo, Shlomi Alkalay, Michael Haselman, Christian Boehn, Oren Firestein, Alessandro Forin, Kang Su Gatlin, Mahdi Ghandi, Stephen Heil, Kyle Holohan, Tamas Juhasz, Ratna Kumar Kovvuri, Sitaram Lanka, Friedel van Megen, Dima Mukhortov, Prerak Patel, Steve Reinhardt, Adam Sapek, Raja Seera, Balaji Sridharan, Lisa Woods, Phillip Yi-Xiao, Ritchie Zhao, and Doug Burger. Accelerating Persistent Neural Networks at Datacenter Scale. In Hot Chips 27, 2017.
[18] DPDK. DPDK: Data Plane Development Kit. http://dpdk.org/about, 2018.
[19] Gokhan Sayilar and Derek Chiou. Cryptoraptor: High throughput reconfigurable cryptographic processor. In Proceedings of the 2014 IEEE/ACM International Conference on Computer-Aided Design, ICCAD ’14, pages 154–161, Piscataway, NJ, USA, 2014. IEEE Press.
[20] J. Fowers, J. Y. Kim, D. Burger, and S. Hauck. A scalable high-bandwidth architecture for lossless compression on fpgas. In 2015 IEEE 23rd Annual International Symposium on Field Programmable Custom Computing Machines, pages 52–59, May 2015.
[21] Yibo Zhu, Haggai Eran, Daniel Firestone, Chuanxiong Guo, Marina Lipshteyn, Yehonatan Liron, Jitendra Padhye, Shachar Raindel, Mohamad Haj Yahia, and Ming Zhang. Congestion control for large-scale rdma deployments. In Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, SIGCOMM ’15, pages 523–536, New York, NY, USA, 2015. ACM.
[22] Microsoft. Server/ProjectOlympus. www.opencompute.org/wiki/Server/ProjectOlympus, 2018.
[23] P. P. Deepthi and P. S. Sathidevi. Design, implementation and analysis of hardware efficient stream ciphers using lfsr based hash functions. Comput. Secur., 28(3-4):229–241, May 2009.
[24] Microsoft. RSS Hashing Functions. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-functions, Apr 2017.
[25] Microsoft. Registered Input/Output (RIO) API Extensions.https://technet.microsoft.com/enus/library/hh997032(v=ws.11).aspx, Aug 2016.
[26] Injong Rhee, Lisong Xu, Sangtae Ha, Alexander Zimmermann,Lars Eggert, and Richard Scheffenegger. CUBIC for Fast Long Distance Networks. RFC 8312, February 2018.
[27] Messaging Accelerator (VMA). https://github.com/Mellanox/libvma, 2018.
[28] Microsoft. ExpressRoute overview. https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction, Oct 2017.
[29] Microsoft. Securing Azure customers from CPU vulnerability.https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/, 2018.
[30] Chloe Jian Ma and Erez Cohen. OpenStack and OVS: From Love-Hate Relationship to Match Made in Heaven.https://events.static.linuxfound.org/sites/events/files/slides/Mellanox%20OPNFV%20Presentation%20on%20OVS%20Offload%20Nov%2012th%202015.pdf, Nov 2012.
[31] Jad Naous, David Erickson, G. Adam Covington, Guido Appenzeller, and Nick McKeown. Implementing an openflow switch on the netfpga platform. In Proceedings of the 4th ACM/IEEE Symposium on Architectures for Networking and Communications Systems, ANCS ’08, pages 1–9, New York, NY, USA, 2008. ACM.
[32] Rui Miao, Hongyi Zeng, Changhoon Kim, Jeongkeun Lee, and Minlan Yu. Silkroad: Making stateful layer-4 load balancing fast and cheap using switching asics. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, SIGCOMM ’17, pages 15–28, New York, NY, USA, 2017. ACM.
[33] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. P4: Programming protocolindependent packet processors. SIGCOMM Comput. Commun. Rev., 44(3):87–95, July 2014.
*英文原文链接：https://www.usenix.org/conference/nsdi18/presentation/firestone。
全文完。
閱讀更多 網絡交換FPGA 的文章
