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

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

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

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

高性能數(shù)據(jù)中心的網(wǎng)絡(luò)演進(jìn)趨勢

軟硬件協(xié)同優(yōu)化方法
在1Gbps時(shí)代，由操作系統(tǒng)網(wǎng)絡(luò)、協(xié)議棧和進(jìn)程調(diào)度引起的開銷是可以接受的，但是隨著定制化硬件的性能越來越高，網(wǎng)絡(luò)協(xié)議棧和進(jìn)程上下文切換引起的開銷變得不可接受。針對(duì)協(xié)議棧的開銷，人們提出了分段卸載功能，將數(shù)據(jù)面卸載到可編程網(wǎng)卡設(shè)備而在處理器上僅對(duì)控制面進(jìn)行處理；在用戶側(cè)，應(yīng)用程序通過BSD Socket接口和協(xié)議棧通信，然而協(xié)議棧進(jìn)程和網(wǎng)卡驅(qū)動(dòng)程序位于內(nèi)核態(tài)，頻繁發(fā)生的用戶態(tài)和內(nèi)核態(tài)上下文切換和數(shù)據(jù)緩沖區(qū)的拷貝帶來了極大的CPU開銷。為了解決這個(gè)問題，提出了諸如英特爾的DPDK的用戶態(tài)協(xié)議棧，這些協(xié)議棧大多涉及或支持無鎖的Ring操作，更換了用戶Socket API，采用內(nèi)存重映射等技術(shù)實(shí)現(xiàn)DMA零拷貝技術(shù)?？梢姡捎密浻布f(xié)同設(shè)計(jì)方法是優(yōu)化網(wǎng)絡(luò)中心的最佳方案。

RDMA技術(shù)
RDMA(RemoteDirect Memory Access)技術(shù)全稱遠(yuǎn)程直接內(nèi)存訪問，就是為了解決網(wǎng)絡(luò)傳輸中服務(wù)器端數(shù)據(jù)處理的延遲而產(chǎn)生的。RDMA有以下三個(gè)特性：
Remote：無CPU參與，數(shù)據(jù)通過網(wǎng)絡(luò)與遠(yuǎn)程機(jī)器間進(jìn)行數(shù)據(jù)傳輸。
Direct：沒有內(nèi)核態(tài)的切換，有關(guān)發(fā)送傳輸?shù)乃袃?nèi)容都卸載到網(wǎng)卡上。
Memory：在用戶空間虛擬內(nèi)存與RNIC網(wǎng)卡直接進(jìn)行數(shù)據(jù)傳輸不涉及到系統(tǒng)內(nèi)核，沒有額外的數(shù)據(jù)移動(dòng)和復(fù)制。

值得注意的是，RDMA沒有使用標(biāo)準(zhǔn)的TCP/IP協(xié)議，而是提出了自己的一套傳輸協(xié)議，因此不支持廣域網(wǎng)的傳輸，為了支持公有云的設(shè)計(jì)，RDMA在承載網(wǎng)絡(luò)上設(shè)計(jì)了三套標(biāo)準(zhǔn)。
1）實(shí)現(xiàn)在InfiniBand網(wǎng)絡(luò)。InfiniBand是專為RDMA設(shè)計(jì)的一套網(wǎng)絡(luò)，在硬件級(jí)別保證數(shù)據(jù)可靠傳輸。需要專用的IB交換機(jī)和IB網(wǎng)卡，不支持Internet連接，主要適用于私有云和分布式計(jì)算。
2）RoCE(RDMAover Converged Ethernet)，分為V1版本和V2版本。RoCEV1將RDMA協(xié)議運(yùn)行在以太網(wǎng)協(xié)議上，而RoCEV2將RDMA協(xié)議運(yùn)行在UDP協(xié)議上。構(gòu)建RoCE網(wǎng)絡(luò)需要專用網(wǎng)卡，但是交換機(jī)可以兼容標(biāo)準(zhǔn)以太網(wǎng)交換機(jī)，因此可以用于構(gòu)建公有云和數(shù)據(jù)中心。
3）iWarp（internetWide Area RDMA Protocol），iWarp將RDMA協(xié)議運(yùn)行在TCP協(xié)議上，與RoCE具有類似特性。
目前，RoCE由于支持Internet并且較iWarp協(xié)議更加簡單，擁有較大的市場和更好的前景。
另外，針對(duì)Smart NIC的研究現(xiàn)在也被推上高潮，由于采用了嵌入式的CPU，智能網(wǎng)卡可以進(jìn)一步降低對(duì)Host主機(jī)的依賴，因此正在被數(shù)據(jù)中心廣泛采用。

開源100Gbps NIC（Corundum）架構(gòu)簡介

高性能NIC采用基于隊(duì)列和描述符的機(jī)制完成數(shù)據(jù)發(fā)送和接收的調(diào)制解調(diào)。描述符即指向內(nèi)存中數(shù)據(jù)物理地址的一組地址描述邏輯，隊(duì)列被實(shí)現(xiàn)為內(nèi)存中連續(xù)的、可以存放多個(gè)描述符的環(huán)形緩沖區(qū)。網(wǎng)卡的驅(qū)動(dòng)程序發(fā)出內(nèi)存屏障，生成數(shù)據(jù)和對(duì)應(yīng)的描述符后通過門鈴操作告知板卡，板卡獲取描述符后解析，并產(chǎn)生對(duì)數(shù)據(jù)的處理操作。
從系統(tǒng)結(jié)構(gòu)上來看，NIC的頂層包含PCIe IP和DMA接口、100Gbps MAC IP和PHY及相應(yīng)的以太網(wǎng)接口，頂層還需要包含一個(gè)或者多個(gè)Interface接口，一個(gè)Interface接口被實(shí)現(xiàn)為Host下的一個(gè)NIC，即操作系統(tǒng)級(jí)別的網(wǎng)絡(luò)接口。網(wǎng)絡(luò)接口內(nèi)部主要用于戶邏輯的實(shí)現(xiàn)，包括用于維護(hù)NIC隊(duì)列的隊(duì)列管理邏輯，描述符獲取和操作完成報(bào)文寫邏輯、發(fā)送和接收引擎以及發(fā)送調(diào)度程序，用于中間暫存數(shù)據(jù)的分段存儲(chǔ)器。

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

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

基于流水線的隊(duì)列管理

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

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

分段存儲(chǔ)器

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

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

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

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

兩臺(tái)機(jī)器使用光纖連接，U50直接插在主機(jī)的PCIe插槽上，VCU118通過擴(kuò)展的PCIe延長線插到主機(jī)的PCIe插槽上，實(shí)物圖如下：

Alveo U50由于采用半高設(shè)計(jì)，可以直接插入到服務(wù)器或者普通主機(jī)機(jī)箱內(nèi)，VCU118則需要PCIe電纜進(jìn)行連接。

板卡安裝就緒后，燒寫B(tài)it文件，并重新啟動(dòng)系統(tǒng)，裝載Linux驅(qū)動(dòng)，此時(shí)可以使用Linux系統(tǒng)的網(wǎng)絡(luò)工具進(jìn)行查看，在本次測試中，設(shè)置U50板卡的IP地址為192.168.0.128，VCU118板卡的IP為192.168.0.129。而后進(jìn)行網(wǎng)絡(luò)測試，發(fā)現(xiàn)可以正常Ping通，網(wǎng)絡(luò)延時(shí)在2ms左右。(視頻請(qǐng)點(diǎn)擊公眾號(hào)查看）

為了測試TCP連接，我們安裝了FTP傳輸工具用于在兩臺(tái)機(jī)器之間傳輸文件。受限于FTP軟件是雙線程，并且我們使用的機(jī)器采用機(jī)械硬盤，傳輸?shù)乃俾什⒉焕硐?，但是可以證明TCP鏈接是沒有問題的。(視頻請(qǐng)點(diǎn)擊公眾號(hào)查看）

為了測試到高性能NIC的極限性能，我們使用C語言創(chuàng)建UDPSocket鏈接，并不斷發(fā)送1400字節(jié)幀長數(shù)據(jù)。

UDP Socket極限發(fā)包速率

在單線程下，使用BSD Socket可以達(dá)到將近10Gbps的速率，在多線程使用時(shí)受限于CPU瓶頸，我們的最高測試速率達(dá)到了35Gbps，此時(shí)可以發(fā)現(xiàn)CPU性能已經(jīng)接近滿負(fù)載，即使增加更多的線程，網(wǎng)絡(luò)處理速率也不會(huì)增大，非常遺憾的是更高的性能需要在服務(wù)器級(jí)別的主機(jī)上才能進(jìn)一步測試。(視頻請(qǐng)點(diǎn)擊公眾號(hào)查看）
也有網(wǎng)友在服務(wù)器上實(shí)現(xiàn)并分享了自己的測試結(jié)果：

用戶態(tài)協(xié)議棧和用戶套接字簡介

用戶態(tài)協(xié)議棧旨在替換Linux內(nèi)核自帶的協(xié)議棧，并提供零拷貝DMA技術(shù)。網(wǎng)絡(luò)協(xié)議棧一般作為操作系統(tǒng)的組件，運(yùn)行在內(nèi)核態(tài)中，用戶調(diào)用套接字來調(diào)用協(xié)議棧進(jìn)程，此時(shí)會(huì)涉及用戶態(tài)和內(nèi)核態(tài)的上下文切換。Linux協(xié)議棧為了通用性考慮，本身性能并不高。

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

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

DPDK存在以下優(yōu)勢：

1)輪詢：在包處理時(shí)避免中斷上下文切換的開銷，對(duì)于高速大突發(fā)數(shù)據(jù)量的網(wǎng)絡(luò)中心，隨時(shí)都有數(shù)據(jù)到達(dá)。

2)用戶態(tài)驅(qū)動(dòng)：通過UIO技術(shù)將報(bào)文拷貝到應(yīng)用空間處理，規(guī)避不必要的內(nèi)存拷貝和系統(tǒng)調(diào)用，便于快速迭代優(yōu)化。

3)親和性與獨(dú)占：傳統(tǒng)內(nèi)核運(yùn)行時(shí)，調(diào)度器采用負(fù)載均衡機(jī)制，一個(gè)進(jìn)程會(huì)在多個(gè)CPU核心上切換，造成額外開銷，而DPDK特定任務(wù)可以被指定只在某個(gè)核上工作，避免線程在不同核間頻繁切換，保證更多的cache命中。

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

5)軟件調(diào)優(yōu)：cache行對(duì)齊，預(yù)取數(shù)據(jù)，多元數(shù)據(jù)批量操作。

6）無鎖隊(duì)列：DPDK 提供了一種低開銷的無鎖隊(duì)列機(jī)制 Ring，Ring 既支持單生產(chǎn)者單消費(fèi)者，也支持多生產(chǎn)者多消費(fèi)者。內(nèi)部實(shí)現(xiàn)沒有使用鎖，大大節(jié)省了使用開銷。

7）使用rte_mbuf結(jié)構(gòu)體來代替?zhèn)鹘y(tǒng)的sk_buff結(jié)構(gòu)體，可以節(jié)省一次內(nèi)存開銷。

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

后記
業(yè)界和學(xué)術(shù)界也在為提高Smart NIC性能在不懈的努力。如最近斯坦福大學(xué)著名的Nick教授團(tuán)隊(duì)提出的NanoPU（文章題目：The nanoPU: Redesigning the CPU-Network Interface to Minimize RPC Tail Latency，2020年）,100G光口經(jīng)過協(xié)議無關(guān)Match-Aciton多級(jí)流表等內(nèi)部處理邏輯再到內(nèi)部嵌入式RISC-V處理器的回環(huán)時(shí)延僅有65ns。

另外，在100G開源 Corundum 可編程N(yùn)IC的基礎(chǔ)上的對(duì)該開源IP核進(jìn)行改進(jìn)的文章也已經(jīng)出來了，而且，最可貴的是這篇改進(jìn)的文章PANIC也是開源的(OSDI 2020：https://www.usenix.org/conference/osdi20/presentation/lin)。文章針對(duì)目前所有的SmartNIC都不擅長同時(shí)運(yùn)行多個(gè)租戶的卸載問題進(jìn)行了研究并提出了切實(shí)可行的解決方案。相關(guān)研究工作后續(xù)本公眾號(hào)會(huì)持續(xù)跟進(jìn)。