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

近年來，隨著集成電路工藝的不斷進步，大數據與人工智能的興起，數據中心的網絡負載愈來愈高，然而由于摩爾定律和Dennard縮放定律的失效，通用處理器依靠加深流水線深度和增加多核并行都受到功耗墻和存儲器墻的限制。星球級算力需求的增加促使定制化硬件逐漸興起（見公眾號文章：未來已來：ASIC云和行星級應用程序的數據中心），從RDMA到RoCE V2到TOE設備，數據中心網絡從10Gbps發展到40Gbps，目前100Gbps和400Gbps的接口正在成為主流。本文設計的100Gbps網卡基于一款開源100Gbps NIC剛玉（見公眾號文章：業界第一個真正意義上開源100 Gbps NIC Corundum介紹），在理解消化代碼的基礎上，基于其架構將部分核心代碼進行修改，使其更適合于硬件實現，并為后續擴展功能進行了前期預研和準備。

公眾號文章《業界第一個真正意義上開源100 Gbps NIC Corundum介紹》發出后，得到了很多粉絲的關注，大家紛紛留言討論。因此，本文也是對眾多問題的簡單回應。另外，特別感謝Xilinx提供免費試用的Alveo U50網卡，我們把原本搭載在VCU118板卡上的剛玉工程移植到了Alveo U50板卡上，與VCU118板卡一起實現了兩臺普通電腦的100Gbps光纖連接，并進行了非優化加速情況下普通應用的測試。

隨著云計算的興起，越來越多的計算被部署到云端來執行，數據中心的運營模式逐漸云化，從接入模式來看，當前部署的云計算主要分為公有云、私有云和混合云。私有云主要是單位或者個人使用的云計算資源，不對外提供，因此可以不兼容傳統以太網，在諸如高性能的分布式計算應用場景下有較好的應用前景。公有云通過Internet為用戶提供服務，因此需要兼容以太網。再加上需要定制加速的應用越來越多，可編程的Smart NIC逐漸的走上了舞臺中央。

高性能數據中心的網絡演進趨勢

軟硬件協同優化方法

在1Gbps時代，由操作系統網絡、協議棧和進程調度引起的開銷是可以接受的，但是隨著定制化硬件的性能越來越高，網絡協議棧和進程上下文切換引起的開銷變得不可接受。針對協議棧的開銷，人們提出了分段卸載功能，將數據面卸載到可編程網卡設備而在處理器上僅對控制面進行處理；在用戶側，應用程序通過BSD Socket接口和協議棧通信，然而協議棧進程和網卡驅動程序位于內核態，頻繁發生的用戶態和內核態上下文切換和數據緩沖區的拷貝帶來了極大的CPU開銷。為了解決這個問題，提出了諸如英特爾的DPDK的用戶態協議棧，這些協議棧大多涉及或支持無鎖的Ring操作，更換了用戶Socket API，采用內存重映射等技術實現DMA零拷貝技術。可見，采用軟硬件協同設計方法是優化網絡中心的最佳方案。

RDMA技術

RDMA（RemoteDirect Memory Access）技術全稱遠程直接內存訪問，就是為了解決網絡傳輸中服務器端數據處理的延遲而產生的。RDMA有以下三個特性：

Remote：無CPU參與，數據通過網絡與遠程機器間進行數據傳輸。

Direct：沒有內核態的切換，有關發送傳輸的所有內容都卸載到網卡上。

Memory：在用戶空間虛擬內存與RNIC網卡直接進行數據傳輸不涉及到系統內核，沒有額外的數據移動和復制。

值得注意的是，RDMA沒有使用標準的TCP/IP協議，而是提出了自己的一套傳輸協議，因此不支持廣域網的傳輸，為了支持公有云的設計，RDMA在承載網絡上設計了三套標準。

1）實現在InfiniBand網絡。InfiniBand是專為RDMA設計的一套網絡，在硬件級別保證數據可靠傳輸。需要專用的IB交換機和IB網卡，不支持Internet連接，主要適用于私有云和分布式計算。

2）RoCE（RDMAover Converged Ethernet），分為V1版本和V2版本。RoCEV1將RDMA協議運行在以太網協議上，而RoCEV2將RDMA協議運行在UDP協議上。構建RoCE網絡需要專用網卡，但是交換機可以兼容標準以太網交換機，因此可以用于構建公有云和數據中心。

3）iWarp（internetWide Area RDMA Protocol），iWarp將RDMA協議運行在TCP協議上，與RoCE具有類似特性。

目前，RoCE由于支持Internet并且較iWarp協議更加簡單，擁有較大的市場和更好的前景。

另外，針對Smart NIC的研究現在也被推上高潮，由于采用了嵌入式的CPU，智能網卡可以進一步降低對Host主機的依賴，因此正在被數據中心廣泛采用。

開源100Gbps NIC（Corundum）架構簡介

高性能NIC采用基于隊列和描述符的機制完成數據發送和接收的調制解調。描述符即指向內存中數據物理地址的一組地址描述邏輯，隊列被實現為內存中連續的、可以存放多個描述符的環形緩沖區。網卡的驅動程序發出內存屏障，生成數據和對應的描述符后通過門鈴操作告知板卡，板卡獲取描述符后解析，并產生對數據的處理操作。

從系統結構上來看，NIC的頂層包含PCIe IP和DMA接口、100Gbps MAC IP和PHY及相應的以太網接口，頂層還需要包含一個或者多個Interface接口，一個Interface接口被實現為Host下的一個NIC，即操作系統級別的網絡接口。網絡接口內部主要用于戶邏輯的實現，包括用于維護NIC隊列的隊列管理邏輯，描述符獲取和操作完成報文寫邏輯、發送和接收引擎以及發送調度程序，用于中間暫存數據的分段存儲器。

在發送方向上，由驅動更新生產者指針并通過PCIe的下行鏈路通知到板卡寄存器，發送隊列管理邏輯通過Doorbell操作告知發送調度程序。發送調度采用RR調度算法從已啟用的隊列進行調度，而后發送調度向發送引擎發起req請求。發送引擎收到傳輸請求后，向對應隊列發送描述符獲取請求，最終，描述符獲取請求由描述符獲取模塊路由到發送隊列管理模塊，發送隊列管理模塊將對應的狀態響應到描述符獲取模塊，描述符獲取模塊使用DMA接口上的控制接口將描述符從隊列取出后放到中間段RAM，而后將描述符獲取狀態返回到發送引擎。發送引擎根據描述符獲取狀態到中間段RAM取得描述符，而后使用DMA的數據接口將數據從Host搬移到分段存儲器RAM，然后又DMA客戶端將數據從分段存儲器發送到MAC控制器。上述數據操作流程相當復雜，如果采用狀態機控制，將會浪費部分數據通路的帶寬，這樣數據很難達到高性能。高性能NIC往往采用流水線設計，而剛玉NIC中基于操作表和操作指針的設計非常適合網絡流水線的處理，因此我們沿用了這個設計思路并將其擴展到部分數據控制通路上去，后續小節將會詳細介紹采用操作表和操作指針的流水線設計思路。

在接收方向上，傳入的數據包通過流哈希模塊確定目標接收隊列，并為接收引擎生成命令，該命令協調對接收數據路徑的操作。由于同一接口模塊中的所有端口共享同一組接收隊列，因此不同端口上的傳入流將合并到同一組隊列中。接收方向的數據的流程不在贅述。

基于流水線的隊列管理

實際上，NIC中為了提高數據帶寬利用率，幾乎所有的模塊都采用了流水線處理方式來促進高并發。本節以隊列管理模塊來介紹基于操作表和操作指針的流水線設計思路。

Corundum NIC的隊列管理邏輯必須能夠有效地存儲和管理數千個隊列的狀態。為了支持高吞吐量，NIC必須能夠并行處理多個描述符。因此，隊列管理邏輯必須跟蹤多個正在進行的操作，并在操作完成時向驅動程序報告更新的隊列指針。NIC的操作表項包含激活和提交標志、所屬隊列號、和影子指針，操作指針包括操作表開始指針和操作表提交指針，通過不同的指針對操作表不同字段的索引就可以跟蹤當前進行中的不同操作項目進展到哪一個步驟，從而可以觸發流水操作。更詳細的來說，當隊列管理接收到出隊請求時將命令放置到Pipeline同時觸發隊列消息，當命令到達處理周期時，對應隊列的信息已經被索引到，此時可以進行處理，如果出隊被允許，必要的信息會被記錄到操作表，處理邏輯只需要不斷寫入操作表并更新操作指針，可以認為出隊邏輯在處理操作表的表頭，操作被提交時會觸發提交邏輯，提交邏輯處理操作表末并合理的釋放操作表。需要注意的是，操作表只跟蹤正在進行中的處理進程，因此不需要設置太大。它和隊列管理的信息RAM構成了一個雙向鏈表，即隊列信息中需要存入為該隊列服務的最新的操作表項索引，用于維護正確的影子指針。

分段存儲器

為了實現高性能，Corundum在內部使用了自定義分段存儲器接口，該思想與CPU中的剩余緩存技術設計思路類似但又不完全一致。該接口被分成最大128位的段，并且整體寬度是PCIe硬IP內核的AXI流接口的兩倍。例如，將PCIe Gen 3 x16與PCIe硬核中的512位AXI流接口一起使用的設計將使用1024位分段接口，該接口分成8個段，每個128位。與使用單個AXI接口相比，該接口提供了改進的“阻抗匹配”，通過消除背壓和對準問題來提高PCIe鏈路利用率。通過設置基地址和偏移量，分段存儲器可以在每次訪問時保證100%的數據帶寬。

基于Xilinx Alevo U50和VCU118 板卡的測試

Xilinx Alevo U50卡采用賽靈思 UltraScale+? 架構，率先使用半高半長的外形尺寸和 低于75 瓦的低包絡功耗。該卡支持高帶寬存儲器 （HBM2），每秒 100G 網絡連接，面向任意類型的服務器部署。而VCU118則包含了兩個100Gbps光模塊，支持PCIe Gen3 X16，最大128Gbps帶寬，兩塊板卡均可以滿足我們的測試需求。

我們在測試過程中選用了兩臺主流性能機器，它們采用分別Intel 8700K和4770K，配置單如下：

兩臺機器使用光纖連接，U50直接插在主機的PCIe插槽上，VCU118通過擴展的PCIe延長線插到主機的PCIe插槽上，實物圖如下：

Alveo U50由于采用半高設計，可以直接插入到服務器或者普通主機機箱內，VCU118則需要PCIe電纜進行連接。

板卡安裝就緒后，燒寫Bit文件，并重新啟動系統，裝載Linux驅動，此時可以使用Linux系統的網絡工具進行查看，在本次測試中，設置U50板卡的IP地址為192.168.0.128，VCU118板卡的IP為192.168.0.129。而后進行網絡測試，發現可以正常Ping通，網絡延時在2ms左右。（視頻請點擊公眾號查看）

為了測試TCP連接，我們安裝了FTP傳輸工具用于在兩臺機器之間傳輸文件。受限于FTP軟件是雙線程，并且我們使用的機器采用機械硬盤，傳輸的速率并不理想，但是可以證明TCP鏈接是沒有問題的。（視頻請點擊公眾號查看）

為了測試到高性能NIC的極限性能，我們使用C語言創建UDPSocket鏈接，并不斷發送1400字節幀長數據。

UDP Socket極限發包速率

在單線程下，使用BSD Socket可以達到將近10Gbps的速率，在多線程使用時受限于CPU瓶頸，我們的最高測試速率達到了35Gbps，此時可以發現CPU性能已經接近滿負載，即使增加更多的線程，網絡處理速率也不會增大，非常遺憾的是更高的性能需要在服務器級別的主機上才能進一步測試。（視頻請點擊公眾號查看）

也有網友在服務器上實現并分享了自己的測試結果：

用戶態協議棧和用戶套接字簡介

用戶態協議棧旨在替換Linux內核自帶的協議棧，并提供零拷貝DMA技術。網絡協議棧一般作為操作系統的組件，運行在內核態中，用戶調用套接字來調用協議棧進程，此時會涉及用戶態和內核態的上下文切換。Linux協議棧為了通用性考慮，本身性能并不高。

從概念上講：Linux協議棧分為三層，VFS層為應用程序提供套接字API；傳統的TCP/IP層提供I/O復用、擁塞控制、丟包恢復、路由和服務質量保證；網卡層與網卡硬件完成數據收發。VFS層貢獻了網絡協議中極大一部分開銷。內核穿越和套接字描述符鎖為每次操作帶來了開銷，傳輸協議在TCP/IP處理上消耗CPU，其他諸如中斷、進程切換、I/O復用也在消耗CPU；此外，BSD Socket中的send和recv語義會導致協議棧和應用之前的數據復制。

為了解決上述問題，目前有多款開源的用戶態協議棧被提出。其中包括Intel針對高速大并發網絡提出的數據平面開發套件DPDK。Intel-DPDK提供了一套可從linux用戶態空間使用的API來替代傳統的LINUX系統調用，數據將不再跨越Linux內核，而是直接通過Intel-DPDK路徑。注意到，DPDK本身并不具備協議棧功能，而是為用戶提供一套開發套件。目前，已經存在諸如MTCP等基于DPDK的開源用戶協議棧。

DPDK存在以下優勢：

1）輪詢：在包處理時避免中斷上下文切換的開銷，對于高速大突發數據量的網絡中心，隨時都有數據到達。

2）用戶態驅動：通過UIO技術將報文拷貝到應用空間處理，規避不必要的內存拷貝和系統調用，便于快速迭代優化。

3）親和性與獨占：傳統內核運行時，調度器采用負載均衡機制，一個進程會在多個CPU核心上切換，造成額外開銷，而DPDK特定任務可以被指定只在某個核上工作，避免線程在不同核間頻繁切換，保證更多的cache命中。

4）降低訪存開銷：Linux默認采用4KB分頁管理機制，然而在大量使用內存時，將嚴重制約程序的運行性能。Linux2.6后開始支持HUGEPAGE，利用內存大頁HUGEPAGE可以降低TLB miss，利用內存多通道交錯訪問提高內存訪問有效帶寬。

5）軟件調優：cache行對齊，預取數據，多元數據批量操作。

6）無鎖隊列：DPDK 提供了一種低開銷的無鎖隊列機制 Ring，Ring 既支持單生產者單消費者，也支持多生產者多消費者。內部實現沒有使用鎖，大大節省了使用開銷。

7）使用rte_mbuf結構體來代替傳統的sk_buff結構體，可以節省一次內存開銷。

后續的工作和發展方向

通過測試表明，高性能NIC依然存在一些問題，如在接收方向上沒有進行描述符預讀取機制，這將會大大提高接收延遲；沒有加入對虛擬化的支持，由于網絡中心主要面向多用戶服務，因此大多云都需要加入對SRIO-V等虛擬化功能的支持；沒有采用大容量DDR或者更高性能的HBM緩存，這將導致其防抖動性能較差；沒有軟件協議棧與其配合工作，軟硬件協同設計優化趨勢是大勢所趨，在網絡中心上也是如此，高性能NIC需要采用用戶態協議棧來進行優化才能更好的發揮其性能；另外，硬件協議棧分段卸載也是未來發展的方向，未來的高性能NIC勢必也要具備這個功能。

后記

業界和學術界也在為提高Smart NIC性能在不懈的努力。如最近斯坦福大學著名的Nick教授團隊提出的NanoPU（文章題目：The nanoPU： Redesigning the CPU-Network Interface to Minimize RPC Tail Latency，2020年），100G光口經過協議無關Match-Aciton多級流表等內部處理邏輯再到內部嵌入式RISC-V處理器的回環時延僅有65ns。

另外，在100G開源 Corundum 可編程NIC的基礎上的對該開源IP核進行改進的文章也已經出來了，而且，最可貴的是這篇改進的文章PANIC也是開源的（OSDI 2020：https://www.usenix.org/conference/osdi20/presentation/lin）。文章針對目前所有的SmartNIC都不擅長同時運行多個租戶的卸載問題進行了研究并提出了切實可行的解決方案。相關研究工作后續本公眾號會持續跟進。

審核編輯：何安