一種面向可編程確定性零拷貝的FPGA加速器

王繼昌,呂高鋒,劉忠沛,楊翔瑞

(國防科技大學 計算機學院,長沙 410073)

0 引 言

當前,云數據中心網絡的吞吐量已經達到百萬兆級,網絡流量趨于多樣化,緊耦合且代碼庫龐大的單體應用架構逐漸被可擴展、易開發的微服務架構[1]所取代.而云函數(serverless)[2]作為一種實現微服務架構的最具代表性的方式,其異步并發、突發不可預測、組件獨立擴展和快速開發迭代的需求對網絡設備提出了新的挑戰.傳統商用的網卡由于硬件設計以及軟件驅動的限制,已經難以滿足部署云函數serverless的高吞吐、可定制和確定性時延的數據傳輸需求,迫切需要一種新型網絡設備破解傳統商用網卡面臨的困境.通過查閱文獻[3,4]可知,傳統商用網卡的局限性體現在如下3個方面:

硬件特性方面的局限性包括:1)可編程性.通常情況下,支持serverless服務的網絡節點需處理多樣化的請求.而基于ASIC的完全定制的網絡設備編程的難度極大,可商用的基于FPGA的設備往往具有無法直接修改的網卡配置.硬件設計的封閉性嚴重限制研究人員在開發新的網絡應用特性時的效用和靈活性;2)確定性.隨著被工業物聯網(IIoT)的興起,云、邊、端的很多業務需要精確地控制點到點的時延和抖動.傳統支持“盡力而為”的以太網的商用網卡無法滿足這一需求.因此,需要一種可提供“準時、準確”數據傳輸服務質量的新一代硬件設備,能夠具備確定時延、確定抖動的能力以及對多個隊列的精確傳輸控制;3)數據拷貝.網卡與用戶程序之間頻繁的數據拷貝從根本上限制了微服務的高性能數據包處理.當報文到達網卡后,網卡通過直接內存訪問(DMA)技術將報文拷貝至主機內存中的環形緩沖區(ring buffer);隨后網卡產生硬件中斷以通知主機CPU接收到一個報文(每個報文一個中斷);CPU為報文分配一個套接字緩沖區(skb),送到協議棧對報文進行層層解析.最終接收端的應用程序通過套接字的recv()接口陷入內核態,將數據從內核復制到用戶空間進行處理.發送過程按相反順序執行.過程中,需經歷1次DMA拷貝、1次CPU拷貝.研究數據[2]表明,單個報文的CPU拷貝消耗500-2000個時鐘周期以及3倍于報文大小的內存.頻繁的CPU拷貝會消耗服務器大量的資源,數據包將會由于無法及時處理而出現丟包和亂序,導致服務器無法達到高性能的要求.

為克服硬件處理和軟件設計的局限性,構建處理高效的微服務網絡節點.本文提出了面向serverless的可編程確定性零拷貝DMA加速器.在硬件層面實例化多個硬件隊列,設計基于硬件時鐘的確定性發送機制,實現對多個隊列發送進行精確時間控制.在設備驅動層面,引入基于多隊列的零拷貝(Zero-Copy)[5]機制,消除頻繁的數據拷貝帶來的CPU開銷.此外,為增強serverless場景下服務的擴展性和靈活性,在傳統多隊列網卡的RSS(receive side scaling)[3]功能的基礎上,添加基于流規則的數據流分發模塊,可用于擴展針對新興傳輸協議QUIC(Quick UDP Internet Connection)[6-8]的基于流標識(Stream id)的數據分發功能.此外,用戶可通過遠程服務器修改流表中的流規則,實現對設備的轉發行為編程.在實驗評估環節,模擬云數據中心的網絡環境,設計多節點的數據包轉發仿真拓撲,針對FPGA加速器的原型系統在不同隊列數量、不同報文長度條件下的吞吐率和轉發時延進行測試和分析.

本文介紹的支持零拷貝DMA的可編程確定性多隊列加速器的設計、實現和評估,破解現有商用網卡設計在支撐微服務架構的桎梏,其主要創新可歸納為:

1)基于硬件時鐘的精確時間同步設計,對加速器的硬件多隊列的確定性發送控制;

2)基于規則的流分類算法的實現,可根據流量特性和用戶需求匹配流表,實現多樣化的基于硬件隊列的調度;

3)分布式的數據流分發控制代理,網絡中的管理節點可以通過下發流表的方式對數據流分發和封裝行為進行定義,有利于分布式serverless網絡節點的集中管理.

1 零拷貝DMA技術概述

在服務請求數據較大時,中斷和數據拷貝將會占據大量的時鐘周期.硬中斷需要CPU的頻繁的響應,可能導致中斷活鎖(livelock)[9].CPU數據拷貝以及上下文切換消耗大量的內存和時鐘周期.針對硬中斷以及CPU拷貝帶來的性能瓶頸,業內提出用以提高數據的收發效率的零拷貝概念,最具代表性的技術以及框架有pf_ring zc、Netmap、DPDK[10-12]等,其中性能最好[13]的是DPDK,也是本文的主要研究對象.以下通過對比(如表1所示)幾種不同零拷貝DMA技術特征來設計加速器驅動.

表1 零拷貝技術對比Table 1 Comparison of four zero copy technologies

1.1 PF_RINF ZC

PF_RING ZC[10]實現了DNA(Direct NIC Access,直接網卡訪問)技術,將網卡內存和寄存器映射到用戶態.其實現零拷貝的具體流程:1)使用DMA技術,把數據從網卡拷貝到主存(RX buffer)中;2)調用庫函數mmap()直接將RX buffer的數據映射到用戶空間,應用直接訪問RX buffer的數據.PF RING ZC的API強調了便利的多核支持,它不使用標準系統調用,提供自定義的函數(polling),其驅動基于Linux驅動實現.PF_RING ZC處于活動狀態期間,常規應用程序無法使用各自默認的系統接口收發數據.由于PF_RING ZC數據包處理經歷的流程少,可達到與DPDK相同的數據處理效率.

Ntop[14]提供大量應用運行在PF_RING ZC之上,如報文捕獲工具(n2disk[15]),流量監控工具(nProbe[16])等.但是PF_RING ZC必須購買相應的許可證(license)才能使用,且在應用于多隊列網卡時,用戶態的多個應用程序之間需要提前溝通需要使用的隊列號,才能分發數據包,否則容易導致隊列的使用沖突.

1.2 Netmap

Netmap[11]實現零拷貝的方法主要是將網卡的收發報文緩沖區(Packet Buffer)映射到共享內存區域(Shared Memory Region),內存中的環形Netmap ring與網卡中的NIC ring對應,應用程序通過調用Netmap API訪問Netmap ring中的內容.Netmap的網絡驅動主要是對Linux內核的網卡驅動打補丁實現,在執行到open/rx/tx等關鍵邏輯時,轉而去執行Netmap自定義的邏輯.一旦開啟Netmap使能的應用,網卡就會進入“Netmap模式”,在該模式下工作時,報文被轉換成Netmap特定的數據結構,對啟用Netmap的應用可用.在驅動程序中保持這種兼容性可以方便地集成到通用操作系統中.

Netmap已經被整合到FreeBSD內核中[17],且多個應用已經通過采用Netmap提升了性能,如:軟件路由器(Click[18])、虛擬交換機(VALE[19])以及FreeBSD防火墻(ipfw[20]).但是Netmap完全不考慮網卡硬件卸載特性(如VLAN卸載、校驗和卸載、TSO等),沒有其他任何對報文進行處理的庫,不便于進行GRO、GSO、IP分片/重組、QoS、加解密等應用的擴展.

1.3 DPDK

DPDK[12]完美支持多隊列與多核擴展,是當前已知的性能最好的開源零拷貝I/O技術[13].它實現性能加速的方法包括:1)PMD(Poll Mode Driver)輪詢模式驅動.I/O線程周期地輪詢報文到達的標記位,從而避免中斷處理引入的上下文切換的開銷;2)UIO(Userspace I/O)[21]驅動,攔截網卡中斷并重新設置中斷對應的回調函數,將對硬件設備的操作映射為用戶空間對文件的直接操作,規避了用戶態和內核態切換以及數據拷貝的過程;3)HugePage訪存,大頁意味著頁表級數減少,則快表中需要記錄的頁表項數減少,從而降低CPU地址轉換過程中訪問內存的次數,提高訪問內存時TLB命中的概率.4)親和性獨占,將線程綁定在與之親和性高的CPU核上,實現RTC(Run-To-Complete)的運行模式,避免了線程在不同核之間頻繁切換,減少CPU內存訪問的開銷.

DPDK的典型應用包括加速的ovs交換機[22](DPDK vSwitch),以及高性能軟件交換方法(xDPd)[23]等.從表1的特征對比來看,無論在部署、開發還是在性能方面,DPDK都具備其他零拷貝DMA技術和框架無法比擬的優勢,而且DPDK作為一個開源技術,為本文的零拷貝驅動的設計提供了便利條件.

2 可編程確定性多隊列加速器模型

傳統商用網卡在可編程、確定性等方面設計缺陷,無法滿足serverless網絡的服務需求.鑒于此,本節提出如圖1所示的可編程確定性多隊列加速器模型.該加速器模型對比傳統的網卡,在多隊列分派的可編程性、數據包發送的確定性等方面進行了相關的改進設計.結合零拷貝DMA技術大幅提升數據包收發效率的相關研究[24],設計適配該加速器模型的零拷貝驅動,為提升網絡節點的吞吐量提供參考.

圖1 可編程確定性多隊列加速器模型Fig.1 Deterministic multi-queue accelerator model

2.1 模型設計

加速器模型從結構上可分為serverless友好的可編程多隊列,serverless友好的確定性DMA、用戶態DMA零拷貝驅動3個模塊.結合當前網絡服務器的眾核特性,采用可編程的基于規則的流分類器,將輸入數據流精確的轉發到與不同內核綁定的硬件隊列中,提升硬件的并發性.加速器上添加的硬件時鐘部件,與傳輸調度器交互,對每個硬件隊列的傳輸引擎進行控制,實現數據發送的確定性.此外,主機用戶空間的零拷貝驅動,消除傳統數據處理流程中的硬件中斷和數據拷貝開銷,可以進一步提升模型的數據包收發效率.

3個模塊提供各自的特性,而三者之間的交互則是通過由加速器和主機共同管理的硬件描述符環完成.該描述符環位于驅動開辟的內存池中,可由DMA控制器和零拷貝DMA驅動共同操作.每個描述符用于存放數據的物理地址、時間戳和描述符完成標志等信息,硬件描述符環使用的狀態遵循生產者-消費者模式,其狀態變化如圖2所示.描述符環的起始物理地址存入加速器的base寄存器、大小(描述符個數)存入size寄存器,使用寄存器tail和head指針表示描述符生產和消耗的情況.tail與head之間數量就是當前可用描述符的數量avail.驅動寫tail寄存器來生產描述符,硬件隊列寫head寄存器來消費描述符,兩者通過讀寫寄存器的方式進行交互.加速器與主機之間的數據包流通則通過DMA控制器與PCIe總線協同完成.確定性DMA的功能由驅動在硬件描述符環中寫入帶有自定義時間戳字段的描述符,結合PTP硬件時鐘的精確對時功能實現.

圖2 硬件描述符使用Fig.2 Hardware descriptor usage

2.2 serverless友好的可編程多隊列

可編程多隊列模塊包含RSS流分類和硬件多隊列兩個組成部分.其中,RSS流分類是可編程多隊列模塊的核心組件,完成基于規則的流分類和轉發工作.每個硬件隊列由rx和tx兩個緩沖區組成.RSS模塊與加速器的網絡接口相關聯,Agent代理用于遠程管理,云服務器通過向Agent下發流表的方式實現對數據轉發動作的編程,Forwarder轉發器負責對傳入的報文根據流表匹配信號進行轉發.

相比傳統商用網卡的RSS設計,RSS流分類不僅具備面向多隊列的數據包分發功能,還擴展多層數據包轉發特性.通常情況下,RSS使用傳統的Toeplitz哈希算法[25],對數據流的5(4)元組進行哈希計算,根據結果將數據流定向到指定的硬件隊列中,在layer 3或者layer 4層實現流的分類.而在傳輸QUIC等新興傳輸協議數據時,還可以根據QUIC單一傳輸對象采用相同流編號(Stream id)的特性,識別QUIC報文負載(payload)中的相同流編號的數據后,轉發到同一個硬件隊列中,實現layer 4.5層的轉發.

轉發器是可編程多隊列模塊的主要功能組件,工作流程如圖3所示.當數據包到達加速器時,網絡接口將接收到的數據包交給與接口綁定的RSS流分類組件,由RSS中定義的報文接收函數處理.首先,由流分類器(Flow Classifier)進行報文頭信息的提取,識別報文類型標識(flag),送入流表(Flow Table)中進行匹配;之后,數據包的控制權與秘鑰(key)值(通常min(核心數,啟用的隊列數),也可以進行自定義)一并被送往轉發中繼器(Repeater).flag在流表中匹配到流表項后,生成信號(signal)交付給轉發中繼器,轉發器結合不同的信號值獲取報文的不同字段(如TCP數據包的五元組,QUIC數據包的Stream id)進行哈希計算,根據哈希值將報文轉發到相應的隊列上.

圖3 RSS多隊列接收流程Fig.3 RSS multi-queue receiving process

流表代理(Agent)作為RSS分類組件的控制器,它通過網絡接口與遠程服務器相連,負責主動為云服務器報告節點變化或者請求服務數據.云服務器也可以通過Agent更新流表內容,實現轉發行為的可編程性.

2.3 面向serverless的的確定性DMA

確定性DMA模塊主要由傳統的DMA組件、傳輸引擎(tx engine)、傳輸調度器(Tx scheduler)[27]以及PTP硬件時鐘(HC)[28]組成.隊列傳輸引擎特定于某個硬件隊列,處理來自傳輸調度器的傳輸指令,負責協調傳輸數據包所需的操作,同時通過寫寄存器的方式控制該隊列的啟用/禁止.傳輸調度器管理多個傳輸引擎.PTP硬件時鐘為加速器提供與主機亞微秒級誤差的高精度對時,結合傳輸調度器對傳輸引擎的控制,實現數據包的準時、準確發送.

當主機提出確定性請求傳輸時,驅動將時間戳與描述符一并寫入硬件描述符環中,DMA控制器感知到描述符環的隊列尾(tail)指針變化后,找到傳輸描述符環中下一個將要使用的描述符.控制器首先讀取時間戳,在通過PCI總線將描述符指向的緩存區數據復制到加速器指定傳輸隊列的同時,將讀取的時間戳信息通報給傳輸調度器.此時傳輸調度器通過與PTP硬件時鐘對時來獲取當前時間,并在時間戳規定的時間點,為該傳輸隊列對應的傳輸引擎發布指令,然后傳輸隊列通過MAC芯片將數據轉發出去.發送完后,加速器更新描述符環的頭(head)指針,DMA控制器啟動硬中斷通知CPU釋放數據緩存區.

以上通過應用程序下發時間戳的方式,結合PTP硬件時鐘的精確對時功能,將數據包發送的控制權轉交給加速器的隊列調度器,從而進一步控制的傳輸引擎來發送報文.不僅簡化了主機的操作流程,還為傳輸提供確定性的控制.

2.4 用戶態零拷貝驅動

用戶態零拷貝模塊由內核態的零拷貝驅動、共享的內存池(mempool)、用戶態的PMD輪詢組成.實現用戶態零拷貝的重點是內核態零拷貝驅動申請的一塊DMA一致性共享內存池.其中包括硬件描述環(ring buffer)、軟件描述符環(sw_ring)以及用于存放收發數據的連續內存空間mbuf.數據包在加速器與應用程序之間的流通,通過DMA+mmap共同實現,所有的數據復制均不需要主機CPU的參與.零拷貝工作流程如圖4所示(以接收數據包為例):①內核態零拷貝驅動初始化時分配一塊內存池,用于存放rx_ring、sw_ring以及mbuf;②申請mbuf;③將新的mbuf的物理地址放入硬件描述符中,將DD(描述符完成)位置為0(0表示可用,1表示不可用);④并將mbuf的虛擬地址賦給軟件描述符(sw_ring),便于應用程序直接訪問;⑤驅動從第一個描述符開始,輪詢硬件描述符的DD位是否為1,如果不為1,則由DMA將硬件描述符獲取到加速器;⑥數據包到達加速器時,DMA控制器從獲取描述符中解析出mbuf的物理地址;⑦將數據包從加速器隊列DMA寫到指定的硬件地址中(對應sw_ring描述符的某個mbuf元素),設置rx_ring和sw_ring描述符的DD位以及其他的信息;⑧應用程序通過PMD輪詢DD位的方式檢查是否有數據包到達,其判定DD位的方式與DMA控制器相反.如果數據包到達則取出數據使用,否則將進入下一個PMD輪詢周期.

圖4 零拷貝工作流程Fig.4 Zero-copy workflow

2.5 面向serverless的CPU的親和性

一般情況下,支持微服務架構的服務器上部署著多個CPU核,并同時運行著多個微服務進程(或者云函數),運行微服務進程使用的信息存儲在每個CPU的緩存中.在進程運行過程中,可能會被操作系統調度到其他CPU核上,由不科學調度導致的CPU緩存命中率降低以及內存污染就會導致程序的運行效率降低或者崩潰.解決這一問題最直觀方式就是將微服務進程綁定到一個CPU核上,為該進程開辟一致性內存空間.CPU核與應用進程綁定后,就會一直在指定的CPU核上以RTC模式運行,減少了進程上下文切換帶來的開銷.

CPU核的親和特性通過RSS多隊列、零拷貝驅動和確定性DMA模塊共同作用實現.零拷貝驅動負責初始化加速器各類寄存器,注冊內核接口,為硬件描述符分配DMA可訪問的緩沖區.驅動讀取加速器中使用寄存器空間公開的參數,如隊列數量以及時間戳等,并結合CPU核的數量,通過Num=Min(硬件隊列數,CPU核數)得出所要激活的隊列數量(Num).此時,驅動為硬件隊列分配各自的內存池,并申請Num個中斷號,使用irqbalance[26]為每個硬件隊列分配唯一的irq號.

CPU親和性在兩個場景適用,一是CPU核的負載均衡.RSS多隊列模塊在接收到數據包時,根據流規則將數據包均衡到不同的硬件隊列,此后該硬件隊列會根據irq號向綁定的CPU核發出中斷請求,DMA控制器將數據包復制到該隊列對應的內存池中.此時應用程序可以通過輪詢irp號對應的內存池獲取用戶數據.第2個場景是基于優先級,將重要的業務進程隔離開,對于部分實時進程設置高優先級,將其綁定到指定核上,既可以保證實時進程的調度,也可以避免其他CPU核上進程被該實時進程干擾.將控制面以及各個數據面進程綁定到不同的CPU核,省卻了反復調度的性能開銷,在進程之間互不干擾的情況下完成工作.

3 性能評估

可編程多隊列加速器理論上可以支持成千上萬的傳輸隊列,用于跨多個終端傳輸數據.該加速器原型與傳統的支持DPDK的網卡相比,主要改進之處在于:1)數據包的轉發可以根據加速器內的流表內容,直接在加速器硬件中完成,同時還配置如VxLAN[27]封裝等多層轉發的功能;2)借助硬件時鐘與發送隊列傳輸調度器的控制,可實現確定性發送,并且對于實時性要求較高的數據流,可以設計更高的發送優先級.

3.1 原型系統實現

原型系統分別在Virtex-7 X 690T和X 2000兩種類型的FPGA板卡上實現.主機配置為Intel(R) Core(TM) i7-10510U CPU,1.8GHz,8G RAM,8 Cores.操作系統采用KylinOS,Linux 4.18.0-25-generic.基于兩種類型的開發板實例化多隊列加速器,配置1個網絡接口,多個硬件隊列,并將加速器的配置參數寫到指定的硬件寄存器中供零拷貝驅動讀取.圖5列舉了在啟用不同數量的硬件隊列時,FPGA資源使用情況.從表中可以看出,開發板可以支持實例化8個硬件隊列的加速器原型,硬件隊列數量每增加1倍,消耗的硬件資源超過原始資源占比的2倍.

圖5 FPGA資源占用Fig.5 Resource utilization of FPGA

加速器原型系統中的可編程多隊列模塊,是加速實現多路并發、可編程、確定性等特性的最核心部件.其中遠程服務器可通過Agent以openflow協議對流表進行編程,轉發其則根據流表的表項對數據包的進行可編程的轉發,轉發器的工作邏輯見算法1描述.

算法1.Rule-based flow classification algorithm

輸入:incoming packetPkt,f low_tableTable,hash_key K

輸出:A action to delivery packet

1.functionFORWARDER(Pkt,Table,K)

2. flag=Flow_Classifier(Pkt)

3. signal=Match(Table,flag,Pkt.tuple)

4. Repeter(Pkt,signal,K)

5.endfunction

6. //Overall process of flow classification and forwarding

7.functionFLOW_CLASSIFIER(Pkt)

8. ExtractPkt.tuple,Pkt.typefrom Pkt.header

9.ifPkt.type !=QUICthenflag ← 2

10.elseflag ← 1

11.endif

12.returnflag

13.endfunction

14. //Get the packet type and flag from the packet header

15.functionMATCH_TABLE(Table,flag,Pkt.tuple)

16.ifPkt.tuple match in Table is drop

17.thenret ← -1

18.elseifPkt.tuple match in Table is forward

19.thenret ← 0

20.elsePkt.tuple match in Table is process ret ← 1

21.endif

22. signal ← flag * ret

23.returnsignal

24.endfunction

25. //Get signal using the flag matching flow table

26.functionREPEATER(Pkt,signal,K)

27.ifsignal=1then

28. Extractstreamidform quic payload

29. num ← hash(K,streamid)

30. delivery tonumth queue for processing

31.elseifsignal=0then

32. num ← hash(K,streamid)

33. delivery tonumth queue for transmition

34.elseifsignal <0thendrop it

35.elsenum ← hash(K,Pkt.tuple)

36. delivery tonumth queue for processing

37.endif

38.endfunction

//The forwarding behavior of different type of packets

零拷貝驅動依然遵循DPDK的主要邏輯,主要在以下幾個方面的工作邏輯進行修改.首先,在零拷貝驅動的設備列表中增加X2000和690T設備型號,通過PCIe設備注冊的方式,提供驅動能力.其次,實現自定義的探測函數與設備釋放函數,并在探測函數中完成硬件資源地址的映射.然后,創建DPDK的以太網設備對象,讀取硬件寄存器中的配置參數,并對該對象進行實例化操作,主要包括對設備功能的配置、收發隊列的初始化、端口的使能、Link及UP/DOWN操作.最后,實現硬件的批量接收和發送函數,支持對每個使能的網絡接口和硬件隊列的數據包收發功能.

3.2 實驗拓撲與設計

實驗拓撲:基于FPGA板卡的多節點網絡拓撲如圖6所示,由發包、轉發和收包3個網絡節點組成.拓撲節點的網絡接口之間使用100G光纖連接.在零拷貝驅動的初始化完成后,可以根據業務的要求來進行數據收發操作.以零拷貝驅動中examples目錄下的pktgen為示例程序,運行后會根據啟用的隊列數,在每個相應的核上啟動一個相應的收發包線程,然后根據轉發規則稍做處理后,直接將接收到的報文分發到其指定的輸出端口.

圖6 實驗拓撲Fig.6 Experiment topology

實驗目的:實驗主要對加速器3個方面的特性進行驗證:1)零拷貝驅動的實現,在雙主機端運行示例程序,通過觀察程序運行情況驗證驅動與可編程多隊列加速器的適配;2)加速器轉發行為的可編程性,通過遠程控制器配置轉發節點(X2000)的流表,將來自Host0直接向Host1轉發,驗證對轉發行為的編程;3)多層數據包轉發的擴展性.啟用RSS模塊中的VxLAN網絡虛擬化技術,在3個節點之間建立網絡隧道,增強實驗模型在云數據中心網絡中的可擴展性.

變量和參數:為了實現上述實驗目標,在實驗過程中設置兩個變量,即隊列數量,和數據包長度,以測試不同隊列數量在傳輸不同大小的數據包時的總吞吐量.同時,考慮啟用/禁用加速器的VxLAN虛擬化技術作為變量,進一步驗證加速器的多層轉發功能.此外,還測試了單隊列下各種大小數據包的轉發延遲.編寫一個shell腳本,直接獲得網絡接口的吞吐量,該腳本每隔1秒執行一次命令,將相應的網絡端口流量大小重定向到后臺文本(.txt)中.與直接使用腳本讀取吞吐量的方法不同,獲得延遲測試結果相對復雜.由于網絡拓撲中有3個節點,兩個用于發送和接收流量,一個用于轉發流量.接收節點在網絡接口上捕捉數據包和時間戳,并將數據包以.pcap格式保存,從.pcap文件中提取時間戳數據進行計算.由于數據包數量眾多,本文從數據包中均勻的抽取一小部分用于計算.

過程和計算:為實現上述實驗目標,本文測試不同隊列數(1,2,4,8)在在啟用和禁用VxLAN的情況下,傳輸不同長度數據包(64B,128B,256B,512B,1024B,1536B)時的吞吐率和轉發時延,驗證加速器的多層轉發功能.每個實驗持續了1分鐘.為保證實驗結果的準確性,本文通過加權計算平均值的方法消除誤差.在計算平均總吞吐量時,使用50個獲得的數據來計算平均值.在計算平均延遲時,由于每次獲得的消息數據量巨大(遠遠超過1000條),為方便計算,采用均勻取值的方法,取50條數據進行計算.平均吞吐量和延時的計算方法是 如公式(1)～公式(3)所示:

(1)

(2)

LATk=Timestamp.recv-Timestamp.sent

(3)

3.3 實驗結果與分析

實驗結果如圖7和圖8所示,圖7顯示了平均總吞吐量和報文大小之間的相關性.圖8顯示評估單隊列的平均轉發延遲與傳輸不同大小數據包的關聯.兩個實驗均表明加速器可以適配零拷貝DMA驅動,支持零拷貝數據收發.

圖7 平均吞吐量Fig.7 Throughput with various queues

圖8 平均轉發時延Fig.8 Forwarding latency with various packet sizes

在圖7中,傳輸同一長度的報文時,啟用的隊列數越多,吞吐量越大.而在同樣隊列數的情況下,隨著報文長度的增大,加速器吞吐量增長速率減慢.在報文長度為1536B時,8個隊列的加速器的數據吞吐量可接近線速率(100Gbps).這意味著8核的主機可能滿足線速率轉發需求.為3個節點啟用VxLAN功能后,通過對流表的編程,同樣可以進行報文的收發.對比同等情況下未啟用VxLAN的加速器,雖然吞吐量有所下降,但是影響較小,既驗證了加速器的高吞吐率,又驗證了多層轉發功能.結合FPGA資源占用和吞吐量增益來看,實例化的硬件隊列的數量每增加一倍,所消耗的FPGA硬件資源就需要增加一倍以上,但是吞吐量增益卻小于50%.

圖8顯示了報文長度與平均延遲之間的相關性,不同的數據包大小在發送方和接收方都啟用了單隊列.隨著數據包長度的增加,數據包的發送和接收延遲也隨著增加,而且在數據包長度超過512B時,延遲增加的速率逐漸減慢.由于中間節點直接數據包,所以一次發送和接收的延時應該是計算出的平均延時的一半.例如,傳輸64B數據包的平均延遲約為6.37,而傳輸1536B時的平均延遲為7.05.該測試的傳輸延遲接近于目前最先進的ovs-DPDK[28]模型,驗證了加速器的“及時”轉發特性.

以上兩個實驗對加速器的零拷貝驅動適配、數據包收發的高吞吐量以及數據包轉發的可編程和低延遲進行驗證和分析,總體達到了上述實驗目標.未來的工作將繼續致力于serverless友好的可編程確定性零拷貝DMA加速器的開發,主要對多隊列的確定性轉發進行擴展和實現,并進一步探索提升Agent代理與流表之間編程的高效能.

4 結束語

面向微服務的支持零拷貝DMA的可編程確定性加速器是滿足serverless中突發流量、多樣化需求,破解傳統商用網卡局限性的一個可行性嘗試.本文介紹了可編程確定性多隊列FPGA加速器硬件以及配套零拷貝驅動的設計、實現.從部署、性能等多個方面對比了多種零拷貝技術優缺點,根據當前性能最好的DPDK的驅動邏輯設計該加速器的多隊列零拷貝DMA驅動.使用兩種類型的FPGA板卡構建了100G加速器原型,并進行多節點數據包收發評估.實驗表明,本文設計的零拷貝DMA驅動能夠完美的適配加速器,實現多隊列數據包收發的零拷貝,且支持多隊列的數據包轉發的可編程,并擴展了多層次的轉發功能,一定程度上滿足了微服務網絡架構的數據傳輸需求.