https://blog.csdn.net/xdpeter/article/details/106133350
來源：內容由本人微信公眾號「網絡交換FPGA」編譯自「FCCM2020」，謝謝。第一次在csdn上發文章。
FCCM2020在5月4日開始線上舉行，對外免費。我們有幸聆聽了其中一個有關100G開源NIC的介紹，我們對該文章進行了翻譯，並對其中的開源代碼進行了分析並恢復出基於VCU118的工程，通過實際測試感受到了第一款真正意義上的100G開源NIC的強大（很多100G的開源都是基於HLS等非HDL語言，盡管可以轉化成HDL，但電路架構參考意義已經不大）。開源Verilog代碼中每個.v文件都是所有的組合和時序分別用一個always模塊描述，代碼中高位寬分段處理方式，多級流水的架構等很多地方都是非常值得借鑒和學習的地方。我們認為，github是一個寶庫。我覺得現在的研究生培養質量的評價其實就可以看開源項目的參與程度，這完全能反應出一個學生的自學能力和獨立研究的能力。而一個科研工作者，尤其是搞工程或應用基礎研究的，如果沒有做出來一兩個星數100以上的開源項目，就不算成功。歡迎感興趣的同學一起交流討論。以下先附上本次會議的視頻：
（附上本次會議的視頻：）Corundum：開源100 Gbps NIC
我們在Linux下Vivado 2019.1版本下恢復出了Corundum基於VCU118的工程，並在VCU118板子上進行了上板重現。如下圖。
資源利用率也比較小。
上板實測結果如下圖。
摘要
Corundum是一個基於FPGA的開源原型平台，用於高達100Gbps及更高的網絡接口開發。Corundum平台包括一些用於實現實時，高線速操作的核心功能，包括：高性能數據路徑，10G/ 25G / 100G以太網MAC，PCIExpress第3代，自定義PCIeDMA引擎以及本機高精確的IEEE 1588 PTP時間戳。一個關鍵功能是可擴展隊列管理，它可以支持超過10,000個隊列以及可擴展的傳輸調度程序，從而可以對包傳輸進行細粒度的硬件控制。結合多個網絡接口，每個接口多個端口以及每個端口事件驅動的傳輸調度，這些功能可實現高級網絡接口，體系結構和協議的開發。這些硬件功能的軟件接口是Linux網絡協議棧的高性能驅動程序。該平台還支持分散/聚集DMA，校驗和卸載，接收流散列和接收端縮放。一個全面的，基於Python的開放源代碼仿真框架促進了開發和調試，該框架包括整個系統，從驅動程序和PCIExpress接口的仿真模型到以太網接口。通過實現微秒級時分多址（TDMA）硬件調度程序，以100Gbps的線速執行TDMA調度，而沒有CPU開銷，證明了Corundum的強大功能和靈活性。
一、引言與背景
網絡接口控制器（NIC）是計算機與網絡進行交互的網關。NIC構成了軟件協議棧和網絡之間的橋梁，該橋梁的功能定義了網絡接口。網絡接口的功能以及這些功能的實現都在迅速發展。這些變化是由提高線速和支持高性能分布式計算和虛擬化的NIC功能的雙重要求所驅動的。不斷提高的線速導致許多NIC功能必須在硬件而非軟件中實現。同時，需要新的網絡功能，例如對多個隊列的精確傳輸控制，以實現高級協議和網絡體系結構。
為了以實際的線速滿足對新的網絡協議和體系結構的開放式開發平台的需求，我們正在開發一種基於FPGA的開源高性能NIC原型平台。這個稱為Corundum的平台能夠以至少94Gbps的速度運行，是完全開源的，並且連同其驅動程序一起，可以在整個網絡協議棧中使用。該設計既便攜式又緊湊，支持許多不同的設備，同時即使在較小的設備上也留有足夠的資源用於進一步的自定義。Corundum的模塊化設計和可擴展性允許共同優化的硬件/軟件解決方案在現實的環境中開發和測試高級網絡應用程序。
A.動機和以前的工作
通過介紹當前如何在硬件和軟件之間划分現有NIC設計中的網絡接口功能，可以了解開發Corundum的動機。硬件NIC功能分為兩個主要類別。第一類包括簡單的卸載功能，這些功能可以從CPU中刪除某些按數據包進行的處理，例如校驗和/哈希計算和分段卸載，這些功能使網絡協議棧可以批量處理數據包。第二類包括必須在NIC上的硬件中實現才能實現高性能和公平性的功能。這些功能包括流量控制，速率限制，負載平衡和時間戳。
一般來說，NIC的硬件功能內置於專有的專用集成電路（ASIC）中。結合規模經濟，可以低成本實現高性能。但是，這些ASIC的可擴展性受到限制，添加新硬件功能的開發周期可能既昂貴又耗時[1]。為了克服這些限制，已經開發了各種智能NIC和軟件NIC。智能NIC通常通過提供許多可編程處理核心和硬件原語，在NIC上提供強大的可編程性。這些資源可用於從主機上卸載各種應用程序，網絡和虛擬化操作。但是，智能NIC不一定能夠很好地適應高線路速率，並且硬件功能可能會受到限制[1]。
軟件NIC通過繞過大多數硬件卸載功能，在軟件中實現網絡功能來提供最大的靈活性。因此，可以快速開發和測試新功能，但是要進行各種折衷，包括消耗主機CPU周期，並不一定要支持全線速運行。另外，由於軟件固有的隨機中斷驅動特性，要求精確傳輸控制的網絡應用程序的開發是不可行的[2]。盡管如此，許多研究項目[3]–[6]通過修改網絡協議棧或使用諸如Data Plane Development Kit（DPDK）[7]之類的內核繞過框架，在軟件中實現了新穎的NIC功能。
基於FPGA的NIC結合了基於ASIC的NIC和軟件NIC的功能：它們能夠以線速運行並提供低延遲和精確定時，同時新功能的開發周期相對較短。還開發了高性能，基於FPGA的專有NIC。例如，阿里巴巴開發了一個完全定制的基於FPGA的RDMA-onlyNIC，他們用它來運行精密擁塞控制協議（HPCC）的硬件實現[8]。商業產品也存在，包括Exablaze [9]和Netcope [10]提供的產品。
不幸的是，類似於基於ASIC的NIC，可商用的基於FPGA的NIC往往具有無法修改的基本“黑匣子”功能。基本NIC功能的封閉性嚴重限制了它們在開發新的網絡應用程序時的效用和靈活性。
商業上可用的高性能DMA組件，例如Xilinx XDMA內核和QDMA內核，以及Atomic Rules ArkvilleDPDK加速內核[11]都沒有提供完全可配置的硬件來控制傳輸數據流。Xilinx XDMA內核是為計算卸載應用程序而設計的，因此提供了非常有限的排隊功能，並且沒有簡單的方法來控制傳輸調度。Xilinx QDMA內核和Atomic Rules ArkvilleDPDK加速內核通過支持少量隊列並提供DPDK驅動程序而面向網絡應用程序。但是，支持的隊列數量很少（XDMA內核為2K隊列，而Arkville內核為128個隊列）而且兩個內核都不提供用於精確控制數據包傳輸的簡單方法。
另外，還有諸如NetFPGA [12]之類的開源項目，但是NetFPGA項目僅提供用於基於FPGA的常規數據包處理的工具箱，而並非專門為NIC開發而設計的[P1] 。此外，NetFPGA NIC參考設計利用了Xilinx XDMA內核，該內核並非為網絡應用而設計。用Corundum替換NetFPGA板的參考NIC設計中的Xilinx XDMA內核，將提供一個功能更強大，更靈活的原型開發平台。
基於FPGA的分組處理解決方案包括實現網絡應用程序卸載的Catapult [13]和實現FPGA上可重構匹配引擎的FlowBlaze [14]。但是，這些平台將標准的NIC功能留給了單獨的基於ASIC的NIC，並且完全作為“線下突擊”進行操作，沒有提供對NIC調度程序或隊列的明確控制。
其他項目使用軟件實現或部分硬件實現。Shoal [15]描述了一種網絡架構，該網絡架構使用自定義NIC和快速的第1層電交叉點交換機執行小規模路由。Shoal是用硬件構建的，但僅在沒有主機連接的情況下通過綜合流量進行評估。SENIC [3]描述了基於NIC的可擴展速率限制。單獨評估了調度程序的硬件實現，但是系統級評估是在具有自定義排隊規則（qdisc）模塊的軟件中進行的。PIEO [16]描述了一種靈活的NIC調度程序，它是在硬件中單獨進行評估的。NDP [5]是用於數據中心應用程序的拉模式傳輸協議。NDP已通過DPDK軟件NIC和基於FPGA的交換機進行了評估。Loom [6]描述了一種有效的NIC設計，可以使用BESS在軟件中對其進行評估。
Corundum的開發與所有這些項目都不同，因為它是完全開源的，並且可以以實際的線速與標准主機網絡協議棧一起運行。它提供了數千個傳輸隊列，並帶有可擴展的傳輸調度程序，以實現對流的細粒度控制。最后我們建立了一個強大而靈活的開源平台，用於開發結合了硬件和軟件功能的網絡應用程序。
二、實施方式
Corundum具有幾種獨特的體系結構特點。首先，將硬件隊列狀態有效地存儲在FPGA塊RAM中，從而支持數千個可單獨控制的隊列。這些隊列與接口相關聯，每個接口可以具有多個端口，每個端口都有自己的獨立傳輸調度程序。這樣就可以對數據包傳輸進行極其精細的控制。調度器模塊的設計是為了修改或交換的。完全可以實現不同的傳輸調度方案，包括實驗調度器。再加上PTP時間同步，這樣可以實現基於時間的調度，包括高精度的TDMA。
Corundum的設計是模塊化且高度參數化的。可以在綜合時通過Verilog參數設置許多配置和結構選項，包括接口和端口計數，隊列計數，內存大小，調度程序類型等。這些設計參數公開在驅動程序讀取以確定NIC配置的配置寄存器中，使同一驅動程序無需修改即可支持許多不同的板卡和配置。
當前的設計支持Xilinx Ultrascale PCIe硬IP內核接口的PCIe DMA組件。目前尚未實現對其他FPGA中常用的PCIe TLP接口的支持，這是未來的工作。這種支持應該可以在更多的FPGA上進行操作。
Corundum的占用空間相當小，即使在相對較小的FPGA上，也有足夠的空間用於附加邏輯。例如，ExaNIC X10[9]的Corundum設計，是一個雙端口10G設計，具有PCIe gen 3 x8接口和512位內部數據路徑，其消耗的邏輯資源不到第二小的Kintex Ultrascale FPGA(KU035)上可用邏輯資源的四分之一。表一列舉了幾個目標平台的資源，放在本文的最后。
本節的其余部分描述了FPGA上Corundum的實現。首先，給出了主要功能塊的高層概述。然后，討論了幾個獨特的體系結構特征和功能塊的細節。
A.高層概述
CorundumNIC的框圖如圖1所示。從較高的層次來看，NIC由3個主要的嵌套模塊組成。頂層模塊主要包含支持和接口組件。這些組件包括PCI Express硬IP內核和DMA接口，PTP硬件時鍾以及包括MAC，PHY和相關串行器的以太網接口組件。頂層模塊還包括一個或多個接口模塊實例。每個接口模塊都對應於操作系統級別的網絡接口（例如eth0）。每個接口模塊都包含隊列管理邏輯以及描述符和完成處理邏輯。隊列管理邏輯維護所有NIC隊列的隊列狀態-傳輸，傳輸完成，接收，接收完成和事件隊列。每個接口模塊還包含一個或多個端口模塊實例。每個端口模塊都提供一個到MAC的AXI流接口，並包含一個傳輸調度程序，傳輸和接收引擎，傳輸和接收數據路徑以及一個暫存RAM，用於在DMA操作期間臨時存儲傳入和傳出的數據包。
對於每個端口，端口模塊中的傳輸調度程序決定將哪些隊列指定用於傳輸。傳輸調度程序為發送引擎生成命令，這些命令協調傳輸數據路徑上的操作。調度程序模塊是一個靈活的功能塊，可以對其進行修改或替換，以支持任意調度，這些調度可以是事件驅動的。調度程序的默認實現是簡單循環。與同一接口模塊關聯的所有端口共享同一組傳輸隊列，並顯示為操作系統的單個統一接口。通過僅更改傳輸調度程序設置，而不會影響網絡協議棧的其余部分，這可以使流在端口之間遷移或在多個端口之間實現負載平衡。這種動態的，調度程序定義的隊列到端口的映射是Corundum的獨特功能，可以使人們能夠研究新的協議和網絡體系結構，包括並行網絡（例如P-FatTree [17]和光交換網絡，例如RotorNet [18]）。和Opera [19]。
圖1.CorundumNIC的框圖。PCIe HIP：PCIe硬IP內核； AXIL M：AXI lite Master； DMA IF：DMA接口； PTP HC：PTP硬件時鍾； TXQ：傳輸隊列管理器； TXCQ：傳輸完成隊列管理器； RXQ：接收隊列管理器； RXCQ：接收完成隊列管理器； EQ：事件隊列管理器； MAC + PHY：以太網媒體訪問控制器（MAC）和物理接口層（PHY）。
在接收方向，傳入的數據包通過流哈希模塊確定目標接收隊列，並為接收引擎生成命令，這些命令協調對接收數據路徑的操作。由於同一接口模塊中的所有端口共享同一組接收隊列，因此不同端口上的傳入流將合並到同一組隊列中。還可以向NIC添加自定義模塊，以在傳入數據包通過PCIe總線之前對其進行預處理和過濾。
NIC上的組件與多個不同的接口互連，包括AXI lite，AXI流和用於DMA操作的自定義分段存儲器接口，這將在后面討論。AXI lite用於從驅動程序到NIC的控制路徑。它用於初始化和配置NIC組件，並在發送和接收操作期間控制隊列指針。AXI stream接口用於在NIC內傳輸打包數據，包括PCIe傳輸層數據包（TLP）和以太網幀。分段存儲器接口用於將PCIe DMA接口連接到NIC數據路徑以及描述符和完成處理邏輯。
大部分NIC邏輯都運行在PCIe用戶時鍾域中，對於所有當前的設計變體，名義上為250 MHz。異步FIFO用於與MAC接口，這些MAC在串行器中運行，以適當地發送和接收時鍾域-10G為156.25 MHz，25G為390.625 MHz，100G為322.266 MHz。
以下各節描述了NIC中的幾個關鍵功能塊。
B.流水線隊列管理
Corundum NIC和驅動程序之間的數據包數據通信通過描述符和完成隊列進行調解。描述符隊列形成主機到NIC的通信通道，承載有關各個數據包在系統內存中存儲位置的信息。完成隊列構成了NIC到主機的通信通道，其中包含有關已完成的操作和關聯的元數據的信息。描述符和完成隊列被實現為駐留在DMA可訪問的系統內存中的環形緩沖區，而NIC硬件則維護必要的隊列狀態信息。此狀態信息包括指向環形緩沖區DMA地址的指針，環形緩沖區的大小，生產者和使用者指針以及對關聯的完成隊列的引用。每個隊列所需的描述符狀態適合128位。
Corundum NIC的隊列管理邏輯必須能夠有效地存儲和管理數千個隊列的狀態。這意味着隊列狀態必須完全存儲在FPGA的Block RAM（BRAM）或Ultra RAM（URAM）中。由於需要128位RAM，並且URAM塊為72x4096，因此存儲4096個隊列的狀態僅需要2個URAM實例。利用 URAM 實例可以將隊列管理邏輯擴展到每個接口至少處理 32,768 個隊列。
為了支持高吞吐量，NIC必須能夠並行處理多個描述符。因此，隊列管理邏輯必須跟蹤多個正在進行的操作，並在操作完成時向驅動程序報告更新的隊列指針。跟蹤進程中操作所需的狀態比描述符狀態小得多，因此可以將其存儲在觸發器和分布式RAM中。
NIC設計使用兩個隊列管理器模塊：queue_manager用於管理主機到NIC的描述符隊列，而cpl_queue_manager用於管理NIC到主機的完成隊列。除了指針處理，填充處理和門鈴/事件生成方面的一些細微差別外，這些模塊相似。由於相似之處，本節將僅討論queue_manager模塊的操作。
用於存儲隊列狀態信息的BRAM或URAM陣列對於每個讀取操作都需要幾個延遲周期，因此queue_manager是使用流水線結構構建的，以促進多個並發操作。流水線支持四種不同的操作：寄存器讀取，寄存器寫入，出隊/入隊請求和出隊/入隊提交。通過AXI lite接口進行的寄存器訪問操作使驅動程序可以初始化隊列狀態，並提供指向已分配的主機內存的指針，以及在正常操作期間訪問生產者和使用者指針。
C.發送調度程序
Corundum NIC中使用的默認傳輸調度程序是在tx_scheduler_rr模塊中實現的簡單循環調度程序。調度器向發送引擎發送命令，從NIC傳輸隊列中啟動傳輸操作。循環調度器包含所有隊列的基本隊列狀態，一個FIFO用於存儲當前活動隊列並執行循環調度，一個操作表用於跟蹤進程中的傳輸操作。
與隊列管理邏輯類似，循環傳輸調度程序還將隊列狀態信息存儲在FPGA上的BRAM或URAM中，以便可以擴展以支持大量隊列。傳輸調度程序還使用處理流水線來隱藏內存訪問延遲。
傳輸調度器模塊具有四個主要接口：AXI lite寄存器接口和三個stream接口。AXI lite接口允許驅動程序更改調度程序參數並啟用/禁用隊列。當驅動程序將數據包排隊發送時，第一個流接口從隊列管理邏輯提供門鈴事件。第二個流接口將由調度器生成的傳輸命令攜帶到發送引擎。每個命令都包含要發送的隊列索引以及用於跟蹤進程中操作的標簽。最終的流接口將傳輸操作狀態信息返回給調度程序。狀態信息會通知調度程序已傳輸數據包的長度，或者是否由於隊列為空或禁用而導致傳輸操作失敗。
傳輸調度程序模塊可以擴展或替換以實現任意調度算法。這使Corundum可用作評估實驗調度算法的平台，包括SENIC [3]，Carousel [4]，PIEO [16]和Loom [6]中提出的算法。還可能向發射調度器模塊提供其他輸入，包括來自接收路徑的反饋，這些輸入可用於實現新協議和擁塞控制技術，例如NDP [5]和HPCC [8]。將調度程序連接到PTP硬件時鍾可用於支持TDMA，TDMA可用於實現RotorNet [18]，Opera [19]和其他電路交換體系結構。
D.端口和接口
Corundum的獨特體系結構特征是端口和網絡接口之間的分隔，因此多個端口可以與同一接口關聯。當前的大多數NIC每個接口支持一個端口，如圖2a所示。當網絡協議棧將數據包排隊以便在網絡接口上傳輸時，數據包將通過與該接口關聯的網絡端口注入網絡。但是，在Corundum中，每個接口都可以關聯多個端口，因此可以在出隊時由硬件決定將數據包注入到網絡中的哪個端口，如圖2b所示。
圖2. NIC端口和接口架構比較
與同一網絡接口模塊關聯的所有端口共享同一組傳輸隊列，並顯示為操作系統的單個統一接口。這樣，通過僅更改傳輸調度程序設置，就可以在端口之間遷移流或在多個端口之間實現負載平衡，而不會影響其余的網絡協議棧。動態的，由調度程序定義的隊列到端口的映射使人們能夠研究新的協議和網絡體系結構，包括諸如P-FatTree [17]的並行網絡以及諸如RotorNet [18]和Opera [19]的光交換網絡。
E.數據路徑以及發送和接收引擎
Corundum在數據路徑中同時使用了內存映射接口和流接口。AXI stream用於在端口DMA模塊，以太網MAC，校驗和與哈希計算模塊之間傳輸以太網數據包數據。AXI stream還用於將PCIe硬IP內核連接到PCIe AXI lite主模塊和PCIe DMA接口模塊。定制的分段存儲器接口用於將PCIe DMA接口模塊，端口DMA模塊以及描述符和完成處理邏輯連接到內部暫存器RAM。
AXI stream接口的寬度由所需帶寬確定。除以太網MAC外，核心數據路徑邏輯完全在250 MHz PCIe用戶時鍾域中運行。因此，到PCIe硬IP內核的AXI流接口必須與硬核接口寬度匹配-PCIe Gen 3 x8為256位，PCIe Gen 3 x16為512位。在以太網端，接口寬度與MAC接口寬度匹配，除非250 MHz時鍾太慢而無法提供足夠的帶寬。對於10G以太網，MAC接口是156.25 MHz的64位，可以以相同的寬度連接到250 MHz的時鍾域。對於25G以太網，MAC接口在390.625 MHz時為64位，因此必須轉換為128位才能在250 MHz時提供足夠的帶寬。對於100G以太網，Corundum在Ultrascale Plus FPGA上使用Xilinx 100G硬CMAC內核。MAC接口在322.266 MHz時為512位，它以512位在250 MHz時鍾域上連接，因為它需要以大約195 MHz的頻率運行才能提供100 Gbps。
圖3. 圖1的簡化版本，顯示了NIC數據路徑。
NIC數據路徑的框圖如圖3所示，它是圖1的簡化版本。PCIe硬IP內核（PCIe HIP）將NIC連接到主機。兩個AXI stream接口將PCIe DMA接口模塊連接到PCIe硬IP內核。一個接口用於讀寫請求，一個接口用於讀取數據。然后，PCIe DMA接口模塊通過一組DMA接口多路復用器連接到描述符獲取模塊，完成寫入模塊，端口暫存RAM模塊以及RX和TX引擎。在朝向DMA接口的方向上，多路復用器組合了來自多個源的DMA傳輸命令。在相反的方向上，它們路由傳輸狀態響應。它們還管理分段存儲器接口以進行讀取和寫入。頂層多路復用器將描述符流量與分組數據流量結合在一起，為描述符流量提供更高的優先級。接下來，一對多路復用器組合來自多個接口模塊的流量。最后，每個接口模塊內的一個附加多路復用器將來自多個端口實例的分組數據流量組合在一起。
發送引擎和接收引擎負責協調傳輸和接收數據包所需的操作。發送和接收引擎可以處理多個正在進行的數據包，以實現高吞吐量。如圖1所示，發送和接收引擎連接到發送和接收數據路徑中的幾個模塊，包括端口DMA模塊以及哈希和校驗和卸載模塊，以及描述符和完成處理邏輯以及時間戳接口模塊、以太網MAC模塊。
發送引擎負責協調數據包的傳輸操作。發送引擎處理來自傳輸調度程序的特定隊列的傳輸請求。使用PCIe DMA引擎進行低級處理后，數據包將通過傳輸校驗和模塊，MAC和PHY。一旦發送了數據包，發送引擎將從MAC接收PTP時間戳，建立完成記錄，並將其傳遞給完成寫入模塊。
與發送引擎類似，接收引擎負責協調數據包的接收操作。傳入的數據包通過PHY和MAC。在包括哈希和時間戳的底層處理之后，接收引擎將向PCIe DMA引擎發出一個或多個寫請求，以將數據包數據寫出到主機內存中。寫操作完成后，接收引擎將構建一個完成記錄，並將其傳遞給完成寫模塊。
描述符讀取和完成寫入模塊的操作類似於發送和接收引擎。這些模塊處理來自發送和接收引擎的描述符/完成讀/寫請求，向隊列管理器發出入隊/出隊請求，以獲取主機內存中的隊列元素地址，然后向PCIe DMA接口發出請求以傳輸數據。完成寫入模塊還負責通過將發送和接收完成隊列排隊在適當的事件隊列中並寫出事件記錄來處理事件。
F.分段內存接口
對於PCIe上的高性能DMA，Corundum使用自定義分段存儲器接口。該接口被分成最大128位的段，並且整體寬度是PCIe硬IP內核的AXI流接口寬度的兩倍。例如，將PCIe Gen 3 x16與PCIe硬核中的512位AXI流接口一起使用的設計將使用1024位分段接口，該接口分成8個段，每個段128位。與使用單個AXI接口相比，該接口提供了改進的“阻抗匹配”，從而消除了DMA引擎中的對齊和互連邏輯中的仲裁，從而消除了背壓，從而提高了PCIe鏈路利用率。具體地說，該接口保證DMA接口可以在每個時鍾周期執行全寬度，未對齊的讀取或寫入。此外，使用簡單的雙端口RAM（專用於在單個方向上移動的流量）消除了讀寫路徑之間的爭用。
除了使用三個接口（而不是五個）之外，每個網段的運行方式均與AXI lite類似。一個通道提供寫地址和數據，一個通道提供讀地址，一個通道提供讀數據。與AXI不同，不支持突發和重新排序，從而簡化了接口邏輯。互連組件（多路復用器）負責維護操作的順序，即使在訪問多個RAM時也是如此。這些段通過單獨的流控制連接和互連排序邏輯的單獨實例彼此完全獨立地運行。另外，操作是基於單獨的選擇信號而不是通過地址解碼進行路由的。此功能消除了分配地址的需要，並允許使用可參數化的互連組件，這些組件以最少的配置適當地路由操作。
字節地址被映射到分段的接口地址上，最低的地址位確定段中的字節通道，接下來的位選擇段，最高的位確定該段的字地址。例如，在一個1024位分段接口中，分成8個128位段，最低的4個地址位將確定段中的字節通道，接下來的3位將確定該段。其余位確定該段的地址總線。
G.設備驅動程序
Corundum NIC通過內核模塊連接到Linux內核網絡協議棧。該模塊負責初始化NIC，注冊內核接口，為描述符和完成隊列分配DMA可訪問的緩沖區，處理設備中斷以及在內核和NIC之間傳遞網絡流量。
NIC使用寄存器空間公開參數，包括接口數量，端口數量，隊列數量，調度程序數量，最大傳輸單元（MTU）大小以及PTP時間戳和卸載支持。驅動程序在初始化期間讀取這些寄存器，因此它可以配置自身並注冊內核接口以匹配NIC設計配置。這種自動檢測功能意味着驅動程序和NIC松耦合。當在不同的FPGA板，不同的Corundum設計變體和不同的參數設置中使用驅動程序時，通常不需要針對核心數據路徑進行修改。
H.仿真框架
包含了一個廣泛的基於Python的開源仿真框架，以評估完整設計。該框架使用Python庫MyHDL構建，並包括PCI Express系統基礎架構，PCI Express硬IP內核，NIC驅動程序和以太網接口的仿真模型。該仿真框架通過提供整個系統狀態的可視性，有助於調試完整的NIC設計。
PCIe仿真框架的核心由大約4,500行Python組成，並包括PCIe基礎結構組件的事務層模型，其中包括根聯合體，功能，端點和交換機以及高級功能，包括配置空間，功能，總線枚舉，根聯合體內存分配，中斷和其他功能。其他模塊由另外4,000行Python組成，提供FPGA PCIe硬IP核的模型，與模擬的PCIe基礎設施交換事務層流量，並驅動可連接至共同仿真的Verilog設計的信號。
模擬Corundum需要幾行代碼來實例化和連接所有組件。清單1顯示了使用模擬框架發送和接收各種大小的數據包的簡化測試台，在Icarus Verilog中共同模擬了Verilog設計。該測試平台實例化了以太網接口端點，PCIe根聯合體和驅動程序的仿真模型，並將它們連接到協同仿真的設計。然后，它初始化PCIe基礎結構，初始化驅動程序模型，並發送，接收和驗證幾個不同長度的測試數據包。
三、結果
在安裝在Dell R540服務器（雙Xeon 6138）中的Alpha Data ADM-PCIE-9V3板上評估了CorundumNIC的100G變體，該主板連接到同一服務器上的最新商業級NIC（Mellanox ConnectX-5）用QSFP28直接連接銅纜。還對在同一台計算機上安裝的另外兩個Mellanox ConnectX-5 NIC進行了評估，以進行比較。最多使用八個iperf3實例來飽和鏈接。
清單1. NIC測試台的縮寫。包括設置PCIe，以太網接口和驅動程序模型，初始化模擬的PCIe總線和驅動程序以及發送和接收測試數據包。為簡潔起見，大多數信號已刪除。
圖4.Corundum和MellanoxConnectX-5的TCP吞吐量比較。
為了將Corundum與Mellanox ConnectX-5的性能進行比較，最初將兩個NIC的最大傳輸單位（MTU）配置為9000字節。對於此配置，Corundum可以分別實現95.5 Gbps RX和94.4 Gbps TX（圖4a）。在相同條件下，Mellanox ConnectX-5 NIC的RX和TX均達到97.8 Gbps。當運行iperf的其他實例同時在兩個方向上使鏈接飽和時，Corundum的性能將下降到65.7 Gpbs RX和85.9 Gbps TX（圖4b）。對於現有的測試台，對於RX和TX，Mellanox NIC的性能也下降到83.4 Gbps。在全雙工模式下，Corundum和ConnectX-5的性能下降都表明軟件驅動程序可能是導致性能下降的重要原因。具體來說，當前版本的驅動程序僅支持Linux內核網絡協議棧。支持諸如DPDK之類的內核繞過框架的參考設計是未來工作的目標。此設計應提高全雙工模式的性能，並可針對特定應用進行定制。
圖4c和4d比較了1500字節MTU的性能。對於這種情況，Corundum可以分別實現75.0 Gbps RX和72.2 Gbps TX（圖4c），同時實現53.0 Gbps RX和57.6 Gbps TX（圖4d）。隨着iperf實例數量的增加，圖4c中TX和RX之間Corundum的性能差異是由進程內傳輸數據包數量的限制以及PCIe往返延遲引起的。通過將進程內傳輸操作的數量從8個增加到16個，可以驗證這一點。這將速率從65.6 Gbps RX和45.7 Gbps TX提高到了圖4c中所示的75.0 Gbps RX和72.2 Gbps TX速率。為了進行比較，在相同條件下，Mellanox ConnectX-5 NIC可以分別實現93.4 Gbps的RX和86.5 Gbps的TX，同時實現82.7 Gbps的RX和62.0 Gbps的TX。
為了測試PTP時間戳的性能，將兩個10G模式的CorundumNIC連接到用作PTP邊界時鍾的Arista 40G數據包交換機。NIC配置為輸出源自PTP時間的固定頻率信號，該信號由示波器捕獲。在啟用PTP時間戳的情況下實施Corundum時，可以將硬件時鍾與linux ptp同步到50 ns以上。鏈路飽和時，時間同步性能不變。
四、案例研究：時分多址（TDMA）
精確的網絡准入控制是高線路速率下的關鍵網絡功能。Corundum提供了數千個傳輸隊列，可用於在多個終端主機之間同步的精細時間范圍內分離和控制傳輸數據。此功能提供了一個獨特的工具箱，可用於開發新的強大的NIC功能。確定要實現的網絡功能以及這些功能對網絡性能的影響是一個活躍的研究領域[3]–[5]，[16]。
為了演示如何將Corundum用於精確的傳輸控制，我們為TDMA實現了具有固定時間表的簡單參考設計。從此基本設計和Corundum的模塊化結構開始，可以實現針對新型網絡協議的自定義調度程序，這些調度程序對整個體系結構的影響最小。
固定的TDMA時間表可以通過IEEE 1588 PTP在多個主機之間同步。在TDMA調度程序控制模塊的控制下，通過根據PTP時間啟用和禁用傳輸調度程序中的隊列來實現TDMA。隊列啟用和禁用命令在TDMA調度程序控制模塊中生成，並在TDMA調度的每個時隙的開始和結束時發送到發送調度器。TDMA調度器在時隙足夠長的假設下操作，使得TDMA調度器控制模塊可以在當前時隙期間為下一個時隙做准備。另外，在每個時隙中必須有相對少量的隊列處於活動狀態，因此啟用或禁用的第一個和最后一個隊列之間的時滯較小。
TDMA調度程序控制模塊在250 MHz PCIe用戶時鍾域中運行。結果，每個隊列花費4 ns遍歷每個傳輸隊列以准備下一個時隙（8,192個傳輸隊列總計約32.8 us）。類似地，它需要4 ns的時間來生成每個啟用或禁用命令，以發送到傳輸調度程序模塊。
A. TDMA性能
在Alpha DataADM-PCIE-9V3板上評估了具有256個傳輸隊列的100G TDMA變體的Corundum NIC，該板安裝在Dell R540服務器（雙Xeon 6138）上，連接到Mellanox ConnectX-5 NIC。使用了八個實例的iperf3來飽和鏈路，兩個網卡的MTU配置為9 kB。在禁用TDMA的情況下，網卡以94.0 Gbps的速度運行。TDMA調度器被配置為運行一個周期為200 µs的調度，包含兩個100 µs的時隙，在第一個時隙中啟用所有傳輸隊列，在第二個時隙中禁用。在100 Gbps的傳輸數據路徑中，11個數據包的間隔為8 µs（每個數據包11個0.72 µs），再加上1 µs來禁用所有256個隊列，Corundum可以以兩個數據包長度或1.4 µs的精度控制離開網卡的數據。
表I 資源利用
使用200us的時間表，以10 Gbps的線速和1500字節的MTU運行附加測試。該時間段被划分為兩個100 us的時隙。考慮到10 Gbps的傳輸數據路徑中的32個數據包的間隔為38 us（每個數據包32 1.2 us）加上1 us以禁用所有256個隊列，Corundum可以以兩個數據包長度或兩個數據包的精度控制離開NIC的數據 2.4us。
五、結論
在本文中，我們介紹了Corundum，這是一種基於FPGA的開源高性能NIC。初始設計的測量性能提供了現實的線速，足以開發和測試新的網絡應用程序。現有的和計划中的開源參考設計可實現自定義和進一步的性能改進。這些功能為網絡研究和開發提供了強大的原型平台，包括基於NIC的調度程序，例如SENIC [3]，Carousel [4]，PIEO [16]和Loom [6]，新協議和擁塞控制技術，例如 NDP [5]和HPCC [8]。Corundum還啟用了新的並行網絡體系結構，例如P-FatTree [17]，RotorNet [18]和Opera [19]。優化設計以提高較小數據包大小的性能，以及基於精確數據包傳輸為新的網絡協議定制設計是當前工作的目標。
參考資料
[1]D. Firestone, A. Putnam, S. Mundkur, D. Chiou, A. Dabagh, M. Andrewartha, H.Angepat, V. Bhanu, A. Caulfield, E. Chung, H. K. Chandrappa, S. Chaturmohta, M.Humphrey, J. Lavier, N. Lam, F. Liu, K. Ovtcharov, J. Padhye, G. Popuri, S.Raindel, T. Sapre, M. Shaw, G. Silva, M. Sivakumar, N. Srivastava, A. Verma, Q.Zuhair, D. Bansal, D. Burger, K. Vaid, D. A. Maltz, and A. Greenberg, “Azureaccelerated networking: SmartNICs in the public cloud,” in 15th USENIXSymposium on Networked Systems Design and Implementation (NSDI 18). Renton, WA:USENIX Association, Apr. 2018, pp. 51–66. [Online]. Available: https://www.usenix.org/conference/nsdi18/presentation/firestone
[2]B. Stephens, A. Akella, and M. M. Swift, “Your programmable NIC should be aprogrammable switch,” in Proceedings of the 17th ACM Workshop on Hot Topics inNetworks, ser. HotNets ’18. New York, NY, USA: Association for ComputingMachinery, 2018, p. 36–42. [Online]. Available:https://doi.org/10.1145/3286062.3286068
[3]S. Radhakrishnan, Y. Geng, V. Jeyakumar, A. Kabbani, G. Porter, and A. Vahdat,“SENIC: Scalable NIC for end-host rate limiting,” in 11th USENIX Symposium onNetworked Systems Design and Implementation (NSDI 14). Seattle, WA: USENIXAssociation, 2014, pp. 475–488. [Online]. Available:https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/radhakrishnan
[4]A. Saeed, N. Dukkipati, V. Valancius, V. The Lam, C. Contavalli, and A. Vahdat,“Carousel: Scalable traffic shaping at end hosts,” in Proceedings of theConference of the ACM Special Interest Group on Data Communication, ser.SIGCOMM ’17. New York, NY, USA: Association for Computing Machinery, 2017, p.404–417. [Online]. Available: https://doi.org/10.1145/3098822.3098852
[5]M. Handley, C. Raiciu, A. Agache, A. Voinescu, A. W. Moore, G. Antichi, and M.W´ojcik, “Re-architecting datacenter networks and stacks for low latency andhigh performance,” in Proceedings of the Conference of the ACM Special InterestGroup on Data Communication, ser. SIGCOMM ’17. New York, NY, USA: Associationfor Computing Machinery, 2017, p. 29–42. [Online]. Available:https://doi.org/10.1145/3098822.3098825
[6]B. Stephens, A. Akella, and M. Swift, “Loom: Flexible and efficient NIC packetscheduling,” in 16th USENIX Symposium on Networked Systems Design andImplementation (NSDI 19). Boston, MA: USENIX Association, Feb. 2019, pp. 33–46.[Online]. Available: https://www.usenix.org/conference/nsdi19/presentation/stephens
[7]“Data plane development kit,” https://www.dpdk.org/.
[8]Y. Li, R. Miao, H. H. Liu, Y. Zhuang, F. Feng, L. Tang, Z. Cao, M. Zhang, F.Kelly, M. Alizadeh, and et al., “HPCC: High precision congestion control,” inProceedings of the ACM Special Interest Group on Data Communication, ser.SIGCOMM ’19. New York, NY, USA: Association for Computing Machinery, 2019, p.44–58. [Online]. Available: https://doi.org/10.1145/3341302.3342085
[9]“Exablaze,” https://exablaze.com/.
[10]“Netcope technologies,” https://www.netcope.com/en.
[11]“Atomic rules,” http://www.atomicrules.com/.
[12]N. Zilberman, Y. Audzevich, G. A. Covington, and A. W. Moore, “NetFPGA SUME:Toward 100 Gbps as research commodity,” IEEE Micro, vol. 34, no. 5, pp. 32–41,Sep. 2014.
[13]A. M. Caulfield, E. S. Chung, A. Putnam, H. Angepat, J. Fowers, M. Haselman, S.Heil, M. Humphrey, P. Kaur, J.-Y. Kim, and et al., “A cloud-scale accelerationarchitecture,” in The 49th Annual IEEE/ACM International Symposium onMicroarchitecture, ser. MICRO-49. IEEE Press, 2016.
[14]S. Pontarelli, R. Bifulco, M. Bonola, C. Cascone, M. Spaziani, V. Bruschi, D.Sanvito, G. Siracusano, A. Capone, M. Honda, F. Huici, and G. Siracusano,“FlowBlaze: Stateful packet processing in hardware,” in 16th USENIX Symposiumon Networked Systems Design and Implementation (NSDI 19). Boston, MA: USENIX Association,Feb. 2019, pp. 531–548. [Online]. Available:https://www.usenix.org/conference/nsdi19/presentation/pontarelli
[15]V. Shrivastav, A. Valadarsky, H. Ballani, P. Costa, K. S. Lee, H. Wang, R.Agarwal, and H. Weatherspoon, “Shoal: A network architecture for disaggregatedracks,” in 16th USENIX Symposium on Networked Systems Design and Implementation(NSDI 19). Boston, MA: USENIX Association, Feb. 2019, pp. 255–270. [Online].Available: https://www.usenix.org/conference/nsdi19/presentation/shrivastav
[16]V. Shrivastav, “Fast, scalable, and programmable packet scheduler in hardware,”in Proceedings of the ACM Special Interest Group on Data Communication, ser.SIGCOMM ’19. New York, NY, USA: Association for Computing Machinery, 2019, p.367–379. [Online]. Available: https://doi.org/10.1145/3341302.3342090
[17]W. M. Mellette, A. C. Snoeren, and G. Porter, “P-FatTree: A multi-channeldatacenter network topology,” in Proceedings of the 15th ACM Workshop on HotTopics in Networks, ser. HotNets ’16. New York, NY, USA: Association forComputing Machinery, 2016, p. 78–84. [Online]. Available: https://doi.org/10.1145/3005745.3005746
[18]W. M. Mellette, R. McGuinness, A. Roy, A. Forencich, G. Papen, A. C. Snoeren,and G. Porter, “RotorNet: A scalable, low-complexity, optical datacenternetwork,” in Proceedings of the Conference of the ACM Special Interest Group onData Communication, ser. SIGCOMM ’17. New York, NY, USA: Association forComputing Machinery, 2017, p. 267–280. [Online]. Available: https://doi.org/10.1145/3098822.3098838
[19]W. M. Mellette, R. Das, Y. Guo, R. McGuinness, A. C. Snoeren, and G. Porter,“Expanding across time to deliver bandwidth efficiency and low latency,” in17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20).Santa Clara, CA: USENIX Association, Feb. 2020. [Online].Available:https://www.usenix.org/conference/nsdi20/presentation/mellette.
文章原文鏈接地址：A. Forencich, A. C. Snoeren, G. Porter, G. Papen, Corundum: An Open-Source 100-Gbps NIC, in FCCM’20, Paper。
源代碼工程地址：https://github.com/ucsdsysnet/corundum。
2020年以來，在網絡交換領域100G開源的文章逐漸增多了。比如同樣在FCCM2020會議上，一篇100G開源的類似於本公眾號之前介紹的1G網絡監兵的研究文章（實驗室自研產品介紹：一種多功能的三端口T型轉發器）：FFShark: A 100G FPGA Implementation of BPF Filtering for Wireshark，介紹了Wireshark的快速FPGA實現FFShark。其結果是一個緊湊的、相對便宜的直通設備，可以插入任何正在運行的100G網絡中。數據包將在FFShark中傳輸，不會中斷，並且附加的延遲最小。開發人員可以隨時向FFShark設備發送標准的Wireshark過濾程序；滿足過濾條件的數據包將被復制並通過單獨的連接發送回開發人員的工作站。也是非常有意思的一個研究，遺憾的是開源關鍵代碼采用的是HLS高層描述。
2019年FPL會議上有一篇文章介紹采用FPGA實現100G TOE的實現方案Limago。一種基於FPGA的TCP/IP協議棧的開源實現，其以100 Gbit/s的速度運行。據我們所知，Limago以這種速度提供了基於FPGA的TCP/IP協議棧的第一個完整描述，從而闡明了必須解決的瓶頸，提出了幾種創新設計以達到必要的吞吐量，並展示了如何整合高級協議功能。例如，Limago支持“ TCP窗口比例”選項，從而解決了“長胖管道”問題。Limago不僅在開放源代碼包中啟用100 Gbit/s以太網鏈路，而且還為基於FPGA的可編程和完全可定制的NIC鋪平了道路。雖然文章開源也是采用HLS實現的，但我們還是采用Vivado2018.2工具恢復了VCU118開發板相應的Verilog工程，不過，采用HLS轉換過來的Verilog代碼，無論是代碼風格還是架構，都遠不如本文介紹的100G剛玉的工程。
后面本公眾號會持續推出系列網絡交換相關的開源項目實踐分享！歡迎關注。
全文完。