本文轉載自：網絡交換FPGA微信公眾號

推薦一篇論文，論文題目翻譯過來為：自適應交換機：用于網絡中心計算的異構交換機體系結構。該論文可以認為是一篇介紹DPU架構的文章。文章由新加坡Xilinx/西交大的 胡成臣老師共同撰寫，發表在2020年12月IEEE Communication Magazine上，其主旨思想，是利用FPGA作為協處理器，補充現有可編程交換ASIC的不足，給出了三個場景（NDP、DISCO、Stateful Firewall）作為例證；代碼已在Github開源。一個新興的范例是采用SmartNIC進行以網絡為中心的計算，它在主機的網絡接口上引入了特定于用戶的處理。作者采取了這一舉措，進一步解決了網絡核心（交換機）中當前專有的處理和計算問題。鏈接：https://ieeexplore.ieee.org/abstract/document/9311937.

以網絡為中心的計算可將計算和數據處理從CPU卸載到并分解到CPU，以支持不斷增長的吞吐量，大數據量和數據中心的信息復雜性。一個新興的范例是采用SmartNIC進行以網絡為中心的計算，它在主機的網絡接口上引入了特定于用戶的處理。在本文中，我們將進一步采取主動行動，以解決網絡核心（交換機）中當前的專有處理和計算問題。我們提出了一種新的硬件架構，稱為自適應交換機。基于對其支持三個用例的原型的測試，我們證明了在可適應的交換機上可以同時實現高吞吐量和處理靈活性。

1. 引言

在嚴格的延遲要求下傳輸海量數據的需求不斷增長，并將CPU推向了現代數據中心可擴展性的極限。從數據中心到網絡接口卡（NIC）的卸載網絡堆棧和計算已越來越多地部署在數據中心中[1]。這種方法稱為SmartNIC，它使人們進一步擁抱網絡內計算或以網絡為中心的計算，以通過網絡卸載和分解計算，存儲和其他功能。在本文中，我們提出了一種適應性強的交換機體系結構，以支持網絡核心中的用戶特定處理和專有協議，以補充主機網絡中現有的SmartNIC。

引入用戶定義的流量穿越交換機的動作的開創性工作是OpenFlow交換機[2]。這個相當不靈活的數據平面后來被開發成為便攜式交換機架構（PSA）[3]。可以從獨立于編程協議的分組處理器（P4）語言[4]靈活定義和編譯PSA兼容數據平面目標。PSA存在一些局限性，這些局限性促使了本文的工作。

首先，PSA僅在數據包到達和/或離開時觸發處理，從而不支持其他事件的操作。例如，在PSA中，很難在新穎的數據平面傳輸協議（NDP）[5]提議中啟用控制，在這種提議中，當緩沖區擁塞時，交換機應該做出反應。稍后將在我們的實驗中詳細介紹NDP的一個使用案例。

其次，PSA在計算操作（例如，代數計算）方面缺乏能力，這阻止了在PSA兼容交換機上部署許多算法。稍后將討論一個利用復雜計算的流量統計方法（折扣計數，DISCO [6]）的具體示例。

第三，PSA最初是為對網絡數據包進行無狀態處理而設計的。PSA通常很難基于歷史狀態進行狀態協議處理和/或狀態計算。為了更好地理解這一點，稍后將討論防火墻[7]用例。

PSA非常適合無狀態和基于轉發的數據平面，但是我們的目標遠不止PSA的范圍：我們的目標是設計一種交換架構，以將計算量卸載和分解到網絡中。在語言級別，P4的最新版本（P4_16）引入了P4_extern的概念，以描述該語言的標準格式不支持的任何功能。但是，沒有靈活的交換機體系結構具有匹配的“ PSA_extern”用于由P4_extern定義的處理。解決方案始終是在添加新的P4_extern時具有新的專用硬件目標。但是，這與PSA作為便攜式可編程數據平面的最初思想相沖突，應該避免。

我們通過提出一種異構硬件交換機體系結構來進行創新，以支持任何可能的P4_extern定義的處理。我們將此架構命名為自適應交換機，我們已經解決了兩個技術挑戰，這是我們的主要貢獻。第一個是自適應交換機的異構硬件體系結構設計。第二個是如何基于自適應開關以最佳方式開發程序并將其映射到目標。據我們所知，這是第一個開關架構，既提供現場可編程門陣列（FPGA）級別的可編程性，又達到與切換專用集成電路（ASIC）相當的吞吐量。借助提出的自適應交換機體系結構，我們可以消除對P4兼容ASIC芯片的限制，并支持事件觸發，復雜的算術計算和狀態處理，所有這些都以線路速率實現。為了評估我們的建議，我們在一個可適配交換機的原型上實現了三個用例，并在評估部分與其他可編程數據平面進行了比較。

2. 架構設計

圖1是自適應交換機的硬件架構的框圖。它由固定交換系統（SS）部分和用戶可編程邏輯（PL）部分組成。SS部分實現了標準交換功能，而PL部分則部署了FPGA以對定制處理進行編程。所提出的體系結構中的SS和PL這兩個部分可以通過兩芯片方法來實現，其中SS可以是具有或不具有P4兼容性的傳統交換ASIC，PL可以是FPGA芯片，即片上多處理器系統（MPSoC）或將FPGA與其他處理器（例如ARM內核）集成在單個SoC中的自適應計算加速平臺（ACAP）芯片。在兩芯片解決方案中，兩個物理上分離的芯片使用PCle或以太網接口或收發器連接。或者，我們還可以用一個高帶寬片上總線（如AXI）來實現單芯片的解決方案。

SS中的交換結構通常采用交叉開關在入口和出口之間進行高速交換。來自網絡接口的數據包在交換矩陣之前/之后經過入口/出口管道。在入口或出口管道中，通常有解析器（提取感興趣的標頭字段），流表（與提取的標頭匹配以執行操作），解析器（重組或/和操作數據包）和流量管理器（緩沖區管理，數據包調度，整形等）。

所有傳入的數據包都首先進入SS，并且大多數數據包完全在SS中處理。只有那些依賴于SS不支持的功能的分組才會被進一步發送給PL進行協同處理。在數據包觸發PL中的處理的情況下，SS將數據包存儲在片上或片外存儲器中，并將專用元數據發送到PL。自定義元數據以承載從PL中進行處理所需的數據包中提取的信息。PL中的處理將更新元數據并將其返回給SS。SS將原始數據包與返回的元數據合并為一個完整的數據包以進行轉發，或者只是丟棄該數據包。

我們引入了一個額外的內存管理單元（MMU），如圖1所示。MMU管理內存以緩沖等待PL更新元數據的數據包。更具體地說，它包括三個主要功能：
1、動態分配存儲塊以存儲數據包。

2、將數據包數據寫入內存。

3、從內存中讀回存儲的數據包數據，并使用從PL返回的元數據組裝輸出數據包。

我們基于兩個觀察或假設來設計自適應交換機體系結構。
1、PL中的大多數處理通常僅基于數據包頭或/和有效載荷中前幾個字節的數據包段。我們的設計僅交換可以靈活定義的元數據，從而保證了SS和PL之間有限的互連帶寬消耗。在極少數情況下，查看整個數據包的處理將用整個數據包填充元數據。

2、并非所有流量都需要在PL中進行處理：否則，相關功能將成為現成交換ASIC的一部分，或者直接轉移到自適應交換體系結構中的SS部分。

考慮到平均數據包長度約為600B，并且假設元數據大小為64B，如果通過PCle Gen4*16進行接口連接，則在不犧牲端口密度的情況下，即使使用最大的交換，也可以在PL中進一步處理20％的流量以12Tb/s作為SS的ASIC。在兩芯片解決方案中，允許10％的端口密度連接SS和PL，同樣，在平均數據包長度為600B，元數據為64B的情況下，所有原始流量可以在PL中進行進一步的處理。

3. PL中用戶定制處理流程

為了有效地映射PL中基于用戶特定數據流的計算，我們引入了微并行處理流水線，如圖1右側。我們將每個處理階段抽象為一個基本處理單元（BPU）。通過將輸入流量負載分配給多個執行引擎，還為每個BPU引入了并行性。執行引擎由操作模塊組成，該模塊對保存在內存中的一組數據進行操作。在通用BPU抽象中，到BPU的輸入（數據流）數量與其前身的執行引擎數量相同，但對于一個BPU中的輸入和輸出數量而言，不一定相同。

數據拆分的優化問題是NP難題，可以從多項式時間的平均除法問題中減少。遵循模擬退火算法解決平均分割問題的思想，我們開發了一種啟發式算法，用于將與流程相關的處理相關數據映射到每個執行引擎中。

在本節的其余部分，我們將回答有關此PL體系結構的兩個問題：
1、如何為BPU開發操作模塊以適合特定于用戶的PL。
2、如何在每個BPU中正確地填充數據內存，以便調度模塊可以盡可能均勻地分配流量負載，從而最終最大化處理吞吐量。

開發流程

我們使用Xilinx P4-SDNet[8]作為開發流程的基礎來構建我們的原型，如圖2所示。P4-SDNet是一種現成的商用產品（COTS），涵蓋了從P4語言到SDNet規范，再到基于FPGA的數據平面的編譯工具鏈。P4-SDNet產品的最新版本支持P4_16，提供了兩個內置的P4_externs。內置的P4_externs支持通過使編譯器前端能夠識別高級描述來展示將編譯器擴展到更多用戶特定處理的方法。另外，我們在編譯器后端使用注釋，這些注釋將轉換為適當的中間表示（IR）（例如SDNet [9]）。規范），最后映射到PL。一般而言，對于用戶特定的PL，還可以使用硬件描述語言（Verilog HDL，VHDL等）進行編碼，然后編譯為BPU和PL中的處理管道，這是另一種選擇。

優化
如前所述，BPU中的調度模塊將流量負載分配給BPU中的多個執行引擎。稻草人解決方案將所有與處理相關的數據復制到每個執行引擎，這通過以循環方式分配流量負載來簡單地實現大吞吐量。但是，每個執行引擎中數據存儲器的大小是有限的，不足以容納處理相關數據的完整副本。由于這個原因，通過回答在每個執行引擎中保留完整處理相關數據的哪個子集來解決數據拆分和分配問題并非易事。目的是通過平衡每個執行引擎中處理的工作量來最大化并行處理吞吐量。不失一般性，我們使用流表來保持對相關數據的處理，并將其表示為一種優化問題。

對象
最大程度地增加可發送到每個執行引擎的工作量。

約束
約束處理
單個執行引擎具有最大吞吐量，無法將更多的負載分派到達到容量限制的執行引擎。

流關聯約束
來自同一流的所有數據包應該由同一處理流水線的同一執行引擎處理，以保持處理依賴關系，避免出現無序問題。

調度約束
流的處理只能調度到執行引擎（其中一個），在該執行引擎中分配要處理該流的數據（例如，執行引擎中的流表具有該流的信息條目）。

內存大小約束
如果數據存儲器的大小小于完整處理相關數據，則只能將完整數據的一部分（例如流表）放入執行引擎中。引入更多的數據副本可以減輕數據訪問沖突，但需要更多的（片上）內存，因此流可能在執行引擎之間具有冗余性。

數據分割的優化問題是NP難問題，可以從多項式時間內的平均分割問題中得到簡化[10]。根據模擬退火算法求解平均分割問題的思想，我們開發了一種啟發式算法，用于將與處理相關的流數據映射到每個執行引擎中。我們介紹了該算法的主要思想；有關詳細信息，請參閱github網站[10]上的代碼。首先，我們使用散列函數將流拆分為多個組；每個組的處理相關數據少于執行引擎可以承載的數據（數據大小約束）。請注意，如果流的匯總工作負載需要多個執行引擎（處理約束），則有包含相同組的執行引擎。其次，我們首先將流組映射到不同的執行引擎中，而不破壞約束。第三，以迭代的方式，我們通過將一個流組從一個源執行引擎隨機移動到另一個目標引擎來調整流組分配到執行引擎。執行引擎的工作負載越多，它將流組移出的概率就越大；而選擇移動組的目標執行引擎的概率與執行引擎的工作負載成反比。如果通過約束檢查的調整能夠改進對目標的評估，那么它將以很大的概率被接受（為了跳出局部搜索陷阱，并不總是接受）。在找到足夠好的解決方案或達到預設的迭代輪數后，調整迭代停止。

在實際應用中，作為啟發式算法輸入的流量分布隨著時間的推移而變化，因此使用遠程控制器來收集執行引擎之間的工作負載變化，作為運行時重新計算和配置的反饋。算法的計算時間評估如下。

3. 評測

我們已經在Xilinx ZC706開發板上實現了自適應開關的原型，其中包含4000余行代碼，包括SS函數，PL映射優化算法和PL中的三個用例。可以在github [10]上訪問測試代碼，在開發過程中我們引用了NetFPGA使用的P4-SDNet工具集的代碼庫。我們利用五種跟蹤進行評估，包括從ISP主干收集的一條真實ISP跟蹤，從LTE基站收集的一條LTE跟蹤，以及按照跟蹤名稱指示的分布的三種綜合跟蹤（指數跟蹤，帕累托跟蹤和統一跟蹤）。

使用案例
擁塞控制：NDP [5]確保在交換機中檢測到擁塞時小批量數據包的低轉發延遲。NDP是事件驅動處理的一個示例，現有交換機無法很好地支持它。為了在自適應交換機中部署NDP，我們在SS部分的MMU中分配邏輯輸出隊列。PL中實現了兩種NDP操作：一種監視隊列深度作為擁塞觸發信號，另一種發送顯式通知以調整數據包大小。前端編譯器將用戶邏輯包裝到操作模塊中，以生成BPU和處理管道。

網絡測量：DISCO [6]是一種有效的流量統計算法，但是由于缺乏指數和對數計算支持，因此在（P4或非P4）COTS交換機中部署DISCO頗具挑戰性。在我們的自適應交換機上的DISCO實現中，PL的輸入元數據包括流ID和每個傳入數據包的長度，而輸出是保存在片上存儲器中的流統計計數器值。我們使用Verilog HDL為DISCO實現P4_extern函數。

有狀態防火墻：我們還提供了一個有狀態防火墻[11]轉發引擎，其形式為可適配交換機支持的P4_extern功能，這對商品交換機是一個挑戰。實現的引擎記錄用于過濾數據包的連接狀態。實現了兩個硬件流表：一個用于基本匹配操作，另一個存儲每個相應流的狀態列表。當來自流的數據包到達時，它根據當前流狀態和感興趣的數據包字段執行操作。它還更新匹配操作表以指示下一個狀態。

4. 實驗結果
我們量化了原型的五種硬件資源消耗。查找表（LUT）用作組合邏輯實現。LUT隨機存取存儲器（LUT RAM）是用于緩存短變量值的寄存器資源。觸發器（FF）電路單元可以由時鐘信號驅動，以建立時序邏輯。Block RAM（BRAM）是片上大型存儲單元。數字信號處理器（DSP）是分布式快速單時鐘周期數學計算核心。

在表1中，我們展示了當我們為每個用例啟用一個分派和20個執行引擎時的結果。表中的結果以“數量/比例”的形式顯示，其中我們顯示了實現原型的FPGA的確切消耗量和占總資源的比例。dispatch行同時考慮了20個解析器（SDNet生成）和一個2020交換機（具有20個均衡器體系結構）的消耗，以將流量負載分配給執行引擎。對于這三個case行，每個執行引擎都包含一個精確匹配表（200個條目）作為數據存儲（在實踐中可以根據需求和硬件容量進行調整）。在擁塞控制用例中，對于擁塞控制用例，有20個輸出端口的40個優先級隊列，每個端口的隊列大小為64 kB。此外，我們還部署了20個計數引擎，在測量情況下總共有4k計數器，在防火墻情況下有20個可編程狀態轉換表。隨著使用的執行引擎、階段、管道和條目數量的增加，資源消耗幾乎呈線性增加。從結果中，我們觀察到一個典型的FPGA足以部署這三個用戶案例。

圖3中，我們描述了增加執行引擎數量時的吞吐量趨勢。我們根據最大頻率、數據總線寬度和平均數據包大小（600b）計算吞吐量。使用更多的執行引擎時，最大頻率會下降，而使用20個以上的執行引擎時，吞吐量增益會變得平緩。我們觀察到，對于擁塞控制和測量用例，原型最多達到8tb/s左右，對于有狀態防火墻用例，原型最多達到6tb/s左右的吞吐量。

通過查看每個用例所需的周期，我們將擁塞控制、網絡測量和防火墻用例的PL處理延遲分別確定為0.130ms、0.136ms和0.142ms。

我們還使用300多行Python代碼在運行時進行配置來實現PL映射優化，并使用PyPy工具集將其部署在Dell R620服務器（具有8G RAM和運行Ubuntu 16.04 LTS OS的2.80 GHz四核Intel CPU）中。和即時（JIT）編譯器來加速Python程序。圖4繪制了本節前面介紹的五個流量跟蹤下的平均計算時間。共有五個燭臺組，分別代表執行引擎（具有一個階段和一個處理管道）數量的不同設置，即K = 4、8、12、16和20個執行引擎。K值較大時，運行時映射優化需要花費較長時間。使用20個執行引擎，在我們測試的所有跟蹤下，計算時間不到8.30 s，置信度為95％。

表2總結了各種常見可編程數據平面的特征，例如，基于軟件的交換機[12]、基于FPGA的交換機[13]和基于P4兼容交換ASIC的交換機[14]。在介紹[11]中，我們提到了很多基于事件驅動的ASIC和基于觸發的ASIC的特性，而在介紹[11]中，我們提到了基于事件驅動的ASIC和基于觸發的ASIC的特性。所提出的可適應性交換機將其自身定位在設計空間中，具有與基于純軟件/FPGA的交換機相似的可編程性和與P4兼容ASIC相當的（稍微低一點）吞吐量。

5. 結論
我們提出了一種適用于網絡中心計算的自適應交換體系結構。Adaptive switch背后的關鍵是利用交換系統提供高吞吐量，同時將硬件可編程處理卸載到FPGA上。我們已經實現了一個原型和三個用例。實驗表明，該結構的靈活性優于現有的固定功能交換機。此外，所實現的設計可以很好地控制資源消耗，以每秒數太比特的速率提供處理吞吐量。盡管PL部分的處理吞吐量仍然小于交換ASIC的吞吐量，但是我們認為，整個分組或所有數據流都不需要在PL中使用用戶定義的處理來處理，因此，自適應交換體系結構具有與COTS交換機兼容的總吞吐量。

審核編輯：何安