Azure 基于 FPGA 的网络加速---Oilbeater

上次在看 Google 介绍自己网络设计的 presentation，下面有观众提问和 Azure 网络加速的比较。才发现 NSDI’18 同期还有 Azure 介绍的基于 FPGA 的网络加速方案。这种区别于 Google 的纯软件实现和只能网卡纯硬件实现的 Datapath 还是很独特的就把论文也找来看了一下。这里主要介绍一下从 Azure 角度其他软硬件实现和 FPGA 方案的对比，工程上的经验以及 Azure 很心机的一个和 AWS，GCP 对比的性能评测。具体的软硬件设计细节，由于我对 FPGA 也不是很了解，感兴趣的读者可以参考文末的论文链接来看看。

背景

第一个大的背景是目前网卡的速率提升超过了 CPU 性能的提升速率。Azure 在 09 年启动时网卡带宽是 1Gbps, 17 年的时候来到了 50Gbps，我刚刚去 Mellanox 的官网看了一下在卖的产品，现在的最大带宽已经到了 200Gbps。十年的时间带宽提升了200倍，而 CPU 显然没有那么大的速率提升。在过去几乎不需要什么优化，单核 CPU 就可以轻松跑满 1Gbps 的带宽，10Gbps 时代就需要很多优化了。而现在已经有了 200Gbps，未来可能还会有带宽更大的网卡，基于 CPU 的网络处理面临着越来越大的挑战。

第二个背景和 Azure 的商业模式相关，也就是公有云靠出卖计算能力来获取收入。由于单机的带宽越来越大，那么就需要保留越来越的 CPU 核心来处理网络数据包，这会造成可对外售卖的 CPU 数量下降，这会影响 Azure 的利润率。

第三个背景是和 GCP 类似，Azure 内部设计了自己的 SDN，网络方面的能力和功能需要随着市场的变化和客户的需求进行高速的迭代，更新的周期往往也是周级别的，传统硬件加速方案无法保持如此快的更新节奏。

在这三个背景下 Azure 还是提出了相当高的设计目标：

还有其他的几个设计目标，但是在我看来和 GCP 在设计目标上最大的区别其实是第四条尽可能少的使用 CPU，这也导致 Azure 选择了一条更靠近硬件的路线。

各种硬件的方案比较

其实所有的方案都可以看成是软硬结合的方案，所谓纯软方案是一种以 CPU 作为硬件基础的方案，而纯硬件的 ASIC 方案是基于硬件电路实现代码逻辑的方案。

ASIC

Azure 早期采用了 ASIC 的方案来完成大量网络数据平面工作，最主要使用到了 SR-IOV 技术，这种方案可以达到几乎和物理网络一致的性能，从性能方面来看是最好的方案。但是这种方案缺点在于可编程性和扩展性是最差的，SDN 只能使用 ASIC 所提供的能力，任何 ASIC 不提供的能力如果用软件实现都会成为一个瓶颈。此外 ASIC 开发周期通常需要 1~2 年，这意味着这块芯片是基于 1 ~ 2 年前的需求而设计的，并且硬件上架后通常要使用五年，这也意味着软件层面的能力需要和硬件绑定一段时间。

Multicore SoC-based NIC

一些 ASIC 上提供了额外的 CPU 可以专门做数据包的通用处理，论文中称其为 Multicore SoC-based NICs，这种硬件提供了通用编程的能力，由专门的嵌入式 CPU 完成处理工作，牺牲了一定的性能来换取更好的可编程能力。这种方案在 10Gbps 的带宽下可以很好的工作，但是在 40Gbps 的带宽下就出现了明显的问题。由于带宽增大了4倍，CPU对应的也需要变为原来的至少4倍，这时CPU的调度的复杂度和延迟的抖动都明显上升。单链接的性能由于受限于单CPU的处理能力，无法随着带宽的提升得到提升，并且在未来面对 100，200 甚至 400Gbps 的带宽时，这种方案能否线性扩展也是个问题。

CPU

不依赖专门硬件的纯软件方案有着最好的灵活性和可编程性，通过 DPDK 这种 OS Bypass 和 CPU poll-mode 优化，可以显著降低数据包处理的延迟和消耗。但是这种方式需要消耗宝贵的宿主机 CPU 资源来处理网络，降低可对外提供售卖服务的 CPU。并且基于 CPU 的方案在大流量和多核的情况下会出现延迟抖动的问题，也很难进行解决。此外通过 Azure 团队的计算，从性价比的考虑来看，这种方式的消耗甚至比 Multicore SoC-based NIC 消耗还要大。

FPGA

和 CPU 相比，FPGA 有着不同的计算模式。CPU 需要一边取指令一边取数据进行计算处理，而 FPGA 中指令是以微代码形式编辑在电路中，然后让数据从电路中流过。同时 FPGA 中有大量可并行计算的资源，并且每个处理步骤也可以设计多级的流水线进一步加强处理的并行度。因此尽管单核的频率上 FPGA 比不过 CPU，但是借助大量的并行可以达到远超 CPU 的吞吐量。此外由于 FPGA 的可编程性，能同时兼顾性能和灵活性，最终 Azure 选择了 FPGA 作为网络的数据平面方案。

关于FPGA的疑问

作者在论文中列举了几个关于 FPGA 的常见疑问并做出了解答。

单纯比逻辑处理部分的体积，完成同样的计算能力 FPGA 大概是 ASIC 的 10 到 20 倍。然而目前来说网卡中的主要部分并不是逻辑处理，SRAM，Transceivers， PCIe，网络接口等占据了更大的空间。并且现代智能网卡增加了可编程的通用部分增加了体积，而 FPGA 也可以根据功能固化一部分逻辑来减小体积。最终的效果是 FPGA 网卡体积是 ASIC 的 2~3 倍，考虑到 FPGA 可编程的灵活性，这部分代价是值得的。

作者说不能透露供应商的价格，而是很奇葩的通过完成相同功能使用到的硅片成本来计算，由于规模效应以及节省下来的大量 CPU，Flash 和 DRAM，FPGA 的投资还是值得的。

FPGA 的编程需要用到 Verilog，是一种硬件编程语言，对于普通的软件工程师来说门槛还是存在的。不过微软研究院曾经做过基于 FPGA 的加速网卡，帮助 Azure 团队处理了很多早期启动的问题。现在 Azure 内部有一个 5 人规模的硬件工程师团队来负责 FPGA 相关开发。通过软硬件工程师联合开发，并通过软件工程的方法论来管理 FPGA 的开发，达到了很好的迭代速率。

性能数据

通过 FPGA 的加速方案，Azure 做到了 VM 和 VM 之间的网络平均延迟为 17 微秒，P99 为 25 微秒，P99.9为80微秒。相比之前软件方案的 50，100，300，在延迟和稳定性上都有了很大的提升。

单线程的吞吐量上，软件的方案受限于单核 CPU 的瓶颈只能做到 8Gbps，而使用了 FPGA 的方案可以跑到 30 Gbps。如果达到同样的带宽，软件方案需要 4 个 CPU 的额外消耗，而 FPGA 在这方面的消耗是 0 CPU。

不过从性能指标来看对比的软件方案应该是非 OS Bypass 的方案，换成类似 DPDK 的方案作对比或许会更有说服力一些。

最后作者鸡贼的做了个 Azure，GCP 和 AWS 三者的网络性能对比。可见 Azure 是完胜的，当然这种自卖自夸还是让人值得怀疑的。不过作者也提到2018年由于 Intel CPU 爆出了大量安全相关的问题(Meltdown 和 Spectre)，公有云不得不打相关补丁导致 CPU 性能下降，对于基于 CPU 的网络方案会有更明显的冲击，基于 FPGA 的方案反而躲过一劫。

总结

和 GCP 的网络方案比，同样是面临性能，灵活性和成本之间的权衡，Azure 选择了可编程硬件来解决问题。对于 Azure 这种规模的基础设施，可编程硬件尽管初期投入和开发成本都比较高，但是长远来看提供了更好的性能，同时节约了成本。不过这种软硬高度结合的玩法也只有这种成规模的玩家才玩得起，我们普通人就当看科幻片就好了。