來源：內容由「網絡交換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 的文章
