本文轉(zhuǎn)載自：網(wǎng)絡(luò)交換FPGA微信公眾號

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

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

1. 引言

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

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

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

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

第三，PSA最初是為對網(wǎng)絡(luò)數(shù)據(jù)包進行無狀態(tài)處理而設(shè)計的。PSA通常很難基于歷史狀態(tài)進行狀態(tài)協(xié)議處理和/或狀態(tài)計算。為了更好地理解這一點，稍后將討論防火墻[7]用例。

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

我們通過提出一種異構(gòu)硬件交換機體系結(jié)構(gòu)來進行創(chuàng)新，以支持任何可能的P4_extern定義的處理。我們將此架構(gòu)命名為自適應交換機，我們已經(jīng)解決了兩個技術(shù)挑戰(zhàn)，這是我們的主要貢獻。第一個是自適應交換機的異構(gòu)硬件體系結(jié)構(gòu)設(shè)計。第二個是如何基于自適應開關(guān)以最佳方式開發(fā)程序并將其映射到目標。據(jù)我們所知，這是第一個開關(guān)架構(gòu)，既提供現(xiàn)場可編程門陣列（FPGA）級別的可編程性，又達到與切換專用集成電路（ASIC）相當?shù)耐掏铝俊＝柚岢龅淖赃m應交換機體系結(jié)構(gòu)，我們可以消除對P4兼容ASIC芯片的限制，并支持事件觸發(fā)，復雜的算術(shù)計算和狀態(tài)處理，所有這些都以線路速率實現(xiàn)。為了評估我們的建議，我們在一個可適配交換機的原型上實現(xiàn)了三個用例，并在評估部分與其他可編程數(shù)據(jù)平面進行了比較。

2. 架構(gòu)設(shè)計

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

SS中的交換結(jié)構(gòu)通常采用交叉開關(guān)在入口和出口之間進行高速交換。來自網(wǎng)絡(luò)接口的數(shù)據(jù)包在交換矩陣之前/之后經(jīng)過入口/出口管道。在入口或出口管道中，通常有解析器（提取感興趣的標頭字段），流表（與提取的標頭匹配以執(zhí)行操作），解析器（重組或/和操作數(shù)據(jù)包）和流量管理器（緩沖區(qū)管理，數(shù)據(jù)包調(diào)度，整形等）。

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

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

2、將數(shù)據(jù)包數(shù)據(jù)寫入內(nèi)存。

3、從內(nèi)存中讀回存儲的數(shù)據(jù)包數(shù)據(jù)，并使用從PL返回的元數(shù)據(jù)組裝輸出數(shù)據(jù)包。

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

2、并非所有流量都需要在PL中進行處理：否則，相關(guān)功能將成為現(xiàn)成交換ASIC的一部分，或者直接轉(zhuǎn)移到自適應交換體系結(jié)構(gòu)中的SS部分。

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

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

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

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

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

開發(fā)流程

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

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

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

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

流關(guān)聯(lián)約束
來自同一流的所有數(shù)據(jù)包應該由同一處理流水線的同一執(zhí)行引擎處理，以保持處理依賴關(guān)系，避免出現(xiàn)無序問題。

調(diào)度約束
流的處理只能調(diào)度到執(zhí)行引擎（其中一個），在該執(zhí)行引擎中分配要處理該流的數(shù)據(jù)（例如，執(zhí)行引擎中的流表具有該流的信息條目）。

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

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

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

3. 評測

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

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

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

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

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

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

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

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

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

表2總結(jié)了各種常見可編程數(shù)據(jù)平面的特征，例如，基于軟件的交換機[12]、基于FPGA的交換機[13]和基于P4兼容交換ASIC的交換機[14]。在介紹[11]中，我們提到了很多基于事件驅(qū)動的ASIC和基于觸發(fā)的ASIC的特性，而在介紹[11]中，我們提到了基于事件驅(qū)動的ASIC和基于觸發(fā)的ASIC的特性。所提出的可適應性交換機將其自身定位在設(shè)計空間中，具有與基于純軟件/FPGA的交換機相似的可編程性和與P4兼容ASIC相當?shù)模ㄉ晕⒌鸵稽c）吞吐量。

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

審核編輯：何安