楊陽，周思遠，王舒鵬

（揚州萬方科技股份有限公司，江蘇揚州，225006）

0 引言

隨著云計算、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術的廣泛應用，數(shù)據(jù)規(guī)模呈現(xiàn)爆炸式增長，導致對于網(wǎng)絡帶寬、延時等性能的依賴性日益增強。網(wǎng)絡帶寬每年以2~3倍的速度增長，目前10G網(wǎng)絡已普及到各個領域，40G/100G甚至400G網(wǎng)絡也在數(shù)據(jù)中心等流量集中的關鍵領域開始大規(guī)模運用。而TCP/IP協(xié)議族作為一種網(wǎng)絡協(xié)議標準，占據(jù)著網(wǎng)絡協(xié)議主流標準地位，其應用最為廣泛。傳統(tǒng)的TCP/IP網(wǎng)絡協(xié)議處理由操作系統(tǒng)內(nèi)核完成分組轉(zhuǎn)發(fā)、校驗、傳輸控制、數(shù)據(jù)分片等流程，并且對于大數(shù)據(jù)量的網(wǎng)絡傳輸，會產(chǎn)生頻繁的I/O中斷以及數(shù)據(jù)拷貝，大幅增加處理器上下文切換開銷和系統(tǒng)總線負載[1,2]。根據(jù)Thumb定律，處理1bit網(wǎng)絡數(shù)據(jù)需要消耗1Hz的CPU處理周期，網(wǎng)絡帶寬的快速增長必將消耗大量的處理器資源，最終導致網(wǎng)絡IO成為系統(tǒng)性能瓶頸。

為解決高速網(wǎng)絡通信中，對于TCP/IP網(wǎng)絡協(xié)議的處理導致的處理器資源過載問題，通信技術領域提出了多種網(wǎng)絡協(xié)議優(yōu)化技術，其中TOE（TCP/IP Offload Engine，TCP/IP卸載引擎）技術[3]，通過將傳統(tǒng)TCP/IP網(wǎng)絡協(xié)議的處理流程由操作系統(tǒng)內(nèi)核卸載至網(wǎng)卡，由網(wǎng)卡硬件執(zhí)行協(xié)議棧處理，從根本上減輕了處理器工作負載，釋放出更多的處理器資源。TOE技術的應用不僅能夠降低主機處理器資源消耗，同時能夠提升網(wǎng)絡吞吐量及縮短網(wǎng)絡延時[4]，具有TOE功能的網(wǎng)絡設備將成為未來數(shù)據(jù)中心構(gòu)建高性能、低功耗網(wǎng)絡基礎設施的首選。而基于FPGA設計實現(xiàn)TOE網(wǎng)卡兼具靈活性及成本優(yōu)勢，適應于數(shù)據(jù)中心網(wǎng)絡環(huán)境。

基于FPGA硬件化實現(xiàn)TCP/IP協(xié)議棧，需要綜合考慮FPGA資源占用率、網(wǎng)絡性能以及可支持的連接數(shù)。目前，商用TOE網(wǎng)卡支持的連接數(shù)在千條量級，基于FPGA的TOE網(wǎng)卡使用多TCP/IP協(xié)議棧實例實現(xiàn)多連接，支持的連接數(shù)相對更少，且資源占用率較高。此外，對于大數(shù)據(jù)塊的通信傳輸，主機仍然需要與TOE網(wǎng)卡進行頻繁的交互，跟蹤、控制數(shù)據(jù)發(fā)送的過程，占用了大量的處理器資源、降低了數(shù)據(jù)吞吐量，對于多連接情景、大數(shù)據(jù)量傳輸，情況將更加嚴重。

云計算、大數(shù)據(jù)等業(yè)務場景下，多連接，大數(shù)據(jù)量傳輸頻繁發(fā)生，在進行TCP/IP協(xié)議卸載的同時，還需要減少主機對于數(shù)據(jù)傳輸?shù)墓芸仡l次，進一步降低網(wǎng)絡IO對于處理器資源的占用，充分釋放PCIe帶寬優(yōu)勢，從而提升網(wǎng)絡性能。本文提出了一種基于FPGA構(gòu)建TCP/IP卸載引擎的設計方法，采用數(shù)據(jù)發(fā)送通道與接收通道分離的架構(gòu)，由協(xié)議共享模塊統(tǒng)一管理連接狀態(tài)及網(wǎng)絡通信事件，控制數(shù)據(jù)收發(fā)過程，能夠處理萬條量級的網(wǎng)絡連接。同時，設計了一種大數(shù)據(jù)塊自動分片傳輸機制，有效降低大數(shù)據(jù)塊發(fā)送的延時及對處理器資源的占用。

1 設計與實現(xiàn)

■ 1.1 系統(tǒng)架構(gòu)

TCP/IP卸載引擎面向多連接TCP/IP網(wǎng)絡傳輸，以可擴展的架構(gòu)形式實現(xiàn)TCP/IP協(xié)議處理的硬件化，從而大幅提高傳輸協(xié)議處理性能，降低對于主機處理器資源的消耗。TOE引擎設計采用發(fā)送路徑與接收路徑相互獨立的基礎架構(gòu)。發(fā)送路徑包括處理組包等工作的發(fā)送協(xié)議引擎以及發(fā)送數(shù)據(jù)緩沖區(qū)；接收路徑包括處理拆包等工作的接收協(xié)議引擎以及接收數(shù)據(jù)緩沖區(qū)。協(xié)議引擎采用流水線模式，用于處理TCP/IP協(xié)議，數(shù)據(jù)緩沖區(qū)Buffer用于緩存網(wǎng)絡發(fā)送或接口的數(shù)據(jù)。發(fā)送路徑與接收路徑共享連接狀態(tài)等公共信息，為保證公共信息的一致性，采用一種基于模塊的鎖方法，有效降低FPGA資源消耗。

發(fā)送、接收引擎相互獨立且使用流水線模式，具備良好的多鏈接并行處理能力；同時基于FPGA片外存儲實現(xiàn)發(fā)送/接收緩沖區(qū)，能夠容納數(shù)以萬計的鏈接并存。

基于FPGA的TCP/IP卸載引擎設計框架[5]如圖1所示，TCP/IP卸載引擎由發(fā)送接口、發(fā)送緩沖Tx Buffer、發(fā)送引擎組成發(fā)送路徑；由接收接口、接收緩沖Rx Buffer、接收引擎組成接收路徑。發(fā)送路徑與接收路徑相互獨立，共享TCP狀態(tài)管理器、事件引擎等公共組件能力。

圖1 TCP/IP協(xié)議卸載引擎設計框架圖

■ 1.2 緩存控制

每個TCP連接在建立時都會被分配一個發(fā)送緩存TxBuffer以及一個接收緩存Rx Buffer。Tx Buffer為環(huán)形緩沖區(qū)，根據(jù)應用場景預先配置環(huán)形緩沖區(qū)容量及數(shù)量。尤其對于數(shù)據(jù)中心分布式存儲場景，如Glusterfs存儲集群采用128KB數(shù)據(jù)條帶、Ceph存儲集群采用4MB數(shù)據(jù)分片，在此類場景下，緩沖區(qū)容量設置為128KB及以上，可以有效降低主機與卸載引擎的交互消耗。Tx Buffer緩存負載數(shù)據(jù)用于超時確認重發(fā)及流量控制。發(fā)送緩存控制器用于維護發(fā)送緩存狀態(tài)表，包括讀取、寫入、刪除、更新操作。發(fā)送緩存狀態(tài)表用于記錄對應發(fā)送緩存的狀態(tài)，屬性包括：

(1)SessionID：TCP鏈接對應的會話ID；

(2)Add：發(fā)送緩存地址；

(3)Producer：生產(chǎn)者指針，標識應用寫入發(fā)送緩存的尾部地址；

(4)Consumer：消費者指針，標識已經(jīng)被發(fā)送并確認的數(shù)據(jù)尾部地址；

(5)Send Window：發(fā)送窗口大??；

(6)ACK：ACK號；

(7)Transmitted： 已發(fā)送指針，標識已經(jīng)被發(fā)送尚未被確認的數(shù)據(jù)尾部地址；

(8)Active：標識對應的發(fā)送緩存是否處于激活使用狀態(tài)。

圖2所示為發(fā)送緩存示意圖，從外部網(wǎng)絡接收的數(shù)據(jù)將由接收引擎進行校驗拆包等協(xié)議處理操作后，放入接收緩存Rx Buffer，通知接收緩存控制器移動Producer指針。在應用程序通過DMA操作取走接收數(shù)據(jù)后，Consumer指針將會被移動。對于亂序發(fā)送的數(shù)據(jù)段，接收引擎根據(jù)計算其段序號計算Offset，放入亂序段數(shù)據(jù)后，移動對應的Length指針，亂序段數(shù)量、及Offset相對Producer的偏移量是預先設定的，當數(shù)量或偏移量超出設定范圍時，相關數(shù)據(jù)段將被丟棄，發(fā)送端由于發(fā)送確認超時，將重新發(fā)送。

圖2 發(fā)送緩存示意圖

Rx Buffer同樣采用環(huán)形緩沖區(qū)，根據(jù)應用場景預先配置環(huán)形緩沖區(qū)容量及數(shù)量。Rx Buffer緩存接收負載數(shù)據(jù)。接收緩存控制器用于維護接收緩存狀態(tài)表，包括讀取、寫入、刪除、更新操作。接收緩存狀態(tài)表用于記錄對應接收緩存的狀態(tài)，屬性包括：

(1)SessionID：TCP鏈接對應的會話ID；

(2)Add：接收緩存地址；

(3)Producer：生產(chǎn)者指針，標識接收數(shù)據(jù)的尾部地址；

(4)Consumer：消費者指針，標識被應用取走的數(shù)據(jù)尾部地址；

(5)Offset:亂序段偏移地址；

(6)Length:亂序段長度；

(7)Active：標識對應的接收緩存是否處于激活使用狀態(tài)。

圖3所示為接收緩存示意圖，從外部網(wǎng)絡接收的數(shù)據(jù)將由接收引擎進行校驗拆包等協(xié)議處理操作后，放入接收緩存Rx Buffer，通知接收緩存控制器移動Producer指針。在應用程序通過DMA操作取走接收數(shù)據(jù)后，Consumer指針將會被移動。對于亂序發(fā)送的數(shù)據(jù)段，接收引擎根據(jù)計算其段序號計算Offset，放入亂序段數(shù)據(jù)后，移動對應的Length指針，亂序段數(shù)量、及Offset相對Producer的偏移量是預先設定的，當數(shù)量或偏移量超出設定范圍時，相關數(shù)據(jù)段將被丟棄，發(fā)送端由于發(fā)送確認超時，將重新發(fā)送。

圖3 接收緩存示意

■ 1.3 連接狀態(tài)管理

TCP/IP協(xié)議的網(wǎng)絡連接狀態(tài)包括Port狀態(tài)、Conne ction狀態(tài)，Port狀態(tài)包括Listening、Active、Closed，Connection狀 態(tài) 包 括 CLOSED，SYN-SENT，SYN-RECEIVED等，連接狀態(tài)管理由TCP狀態(tài)管理器完成。TCP狀態(tài)管理器基于表數(shù)據(jù)結(jié)構(gòu)管理Port及Connection狀態(tài)，同時維護SessionID與由源IP地址、目的IP地址、源Port、目的Port組成的四元組之間的映射。如圖4所示為TCP狀態(tài)管理器對于Connection狀態(tài)表的管理，Port狀態(tài)表采用同樣的管理方式。由于TOE中的接收引擎、發(fā)送引擎、發(fā)送接口的工作流程中都涉及了狀態(tài)表的查詢、更新等操作。狀態(tài)表作為多模塊共享數(shù)據(jù)結(jié)構(gòu)，一方面需要保證并行訪問能力及數(shù)據(jù)一致性；另一方面為適應多連接、高性能網(wǎng)絡應用場景，需要提高訪問操作性能，降低資源消耗。

圖4 TCP狀態(tài)管理器實施框圖

狀態(tài)表采用FPGA片上雙端口BRAM存儲，提供數(shù)據(jù)共享及高性能數(shù)據(jù)操作；狀態(tài)管理器通過模塊讀寫鎖機制，為訪問共享狀態(tài)表的模塊分別創(chuàng)建對應的鎖結(jié)構(gòu)，包括讀寫鎖RWLock及表項索引，從而避免為每一個表項創(chuàng)建鎖，降低存儲資源消耗。外部模塊通過相應的訪問接口首先獲取鎖狀態(tài)，對于同一表項的訪問操作，需要進行加鎖操作，加鎖成功后進行讀寫操作。

■ 1.4 計時器

TOE根據(jù)TCP協(xié)議使用四個計時器，包括重傳計時器Retransmission Timer、 堅 持 計 時 器 Persistent Timer、?；钣嫊r器Keeplive Timer、時間等待計時器Timer_Wait Timer。計時器實現(xiàn)基于表結(jié)構(gòu)，通過遍歷操作計時。計時器表結(jié)構(gòu)每一表項代表一個TCP連接會話，表屬性包括會話ID用于唯一標識TCP連接；時間戳Timestamp用于記錄遍歷次數(shù)；活躍標志Active用于表示該連接是否在計時中。

對計時器表結(jié)構(gòu)的操作包括兩種：一是設置/清空計時器；二是遍歷計時器表。針對預先設置的TOE支持連接數(shù)，計時器表包含對應數(shù)量的表項，一個硬件時鐘周期執(zhí)行一個表項遍歷，在連接計時器有效的情況下，如果Timestamp大于0，則減1，當Timestamp為0時，觸發(fā)相應事件并撤銷計時。

■ 1.5 事件引擎

根 據(jù) TCP協(xié) 議，TOE定 義 了 TX、RT、ACK、ACKNODELAY、SYN、SYN-ACK、FIN、RST事件，事件包括SessionID、類型，并攜帶相關參數(shù)，用于構(gòu)建網(wǎng)絡包。圖5所示為事件引擎的設計框圖，TOE事件來源于接收引擎、定時器，以及發(fā)送接口，事件引擎相應的設置3個FIFO隊列用于事件緩存。調(diào)度器根據(jù)預定義調(diào)度策略進行事件調(diào)度處理，默認為優(yōu)先級策略，為避免接收路徑背壓導致數(shù)據(jù)丟失，設置接收引擎事件為高優(yōu)先級，優(yōu)先調(diào)度。事件路由針對不同的事件類型將事件路由至不同的后續(xù)模塊。對于ACK事件，由ACK-DELAY模塊進行處理，該模塊檢查ACK-DELAY計時器相應的計時表項是否為Active，如果是，ACK事件會與之前被延遲發(fā)送的ACK事件合并，由輸出模塊傳送至發(fā)送引擎；如果計時表項不是激活狀態(tài)，則該表項被設置為Active，ACK事件延遲發(fā)送。對于除SYN與RST外的其他事件，被直接路由至輸出模塊，由輸出模塊將延遲的ACK事件與其合并，推送至發(fā)送引擎，同時撤銷延遲ACK事件的計時。

圖5 事件引擎設計框圖

對于由應用程序通過發(fā)送接口觸發(fā)的數(shù)據(jù)發(fā)送事件，到達事件路由后，由事件路由獲取發(fā)送緩存狀態(tài)，比較未發(fā)送數(shù)據(jù)Producer-Transmitted、可用窗口Send Window-Transmitted，以及預定義的MTU。為減少主機端與TOE網(wǎng)卡的交互頻次，從而有效降低交互開銷，應用觸發(fā)的發(fā)送事件攜帶的數(shù)據(jù)長度如果數(shù)據(jù)發(fā)送事件要求發(fā)送的數(shù)據(jù)長度大于未發(fā)送數(shù)據(jù)、可用窗口、MTU三者的最小值，則發(fā)送事件將被路由至發(fā)送事件切分模塊，否則發(fā)送事件直接輸出。發(fā)送事件切分模塊記錄原始發(fā)送事件數(shù)據(jù)長度，循環(huán)執(zhí)行子事件構(gòu)建、發(fā)送操作。子事件構(gòu)建操作獲取未發(fā)送數(shù)據(jù)、可用窗口、MTU大小，取三者的最小值為數(shù)據(jù)長度，替換原始發(fā)送事件數(shù)據(jù)長度，形成子事件。子事件重新送入發(fā)送接口事件隊列調(diào)度執(zhí)行，對于子發(fā)送事件，事件路由將直接轉(zhuǎn)發(fā)至輸出模塊。

■ 1.6 接收引擎

接收引擎面向數(shù)據(jù)流采用流水線模式設計TCP/IP協(xié)議接收處理流程，如圖6所示。接收引擎使用數(shù)據(jù)通道及元數(shù)據(jù)通道將網(wǎng)絡傳輸數(shù)據(jù)與網(wǎng)絡控制數(shù)據(jù)分離，通過調(diào)整數(shù)據(jù)通道寬度，可以實現(xiàn)不同網(wǎng)絡帶寬的數(shù)據(jù)傳輸。

圖6 接收引擎實施框圖

由物理鏈路接口傳入TCP/IP卸載引擎的IP Package首先進行IP Header的解析，抽取出IP地址及Package長度等IP元數(shù)據(jù)。第二步進行TCP Checksum校驗，對于校驗不一致的Package將被丟棄，對于校驗一致的Package將進行TCP Header的解析，抽取數(shù)據(jù)段序號SEQ Number，確認序號ACK Number，發(fā)送窗口尺寸Window Size以及SYN，ACK，RST等標志Flags。TCP狀態(tài)檢查步驟根據(jù)Port端口號訪問TCP狀態(tài)管理器，檢查Port是否處于有效狀態(tài)；如果Port有效，根據(jù)IP地址、Port端口號檢索鏈接SessionID；根據(jù)SessionID查詢Connection狀態(tài)；如果Package有效，負載數(shù)據(jù)將會被放入Rx Buffer，并通過接收緩存管理器更新接收緩存狀態(tài)表。同時，接收引擎會更新ACK Number、發(fā)送緩存狀態(tài)表的Window Size、設置或清空計時器。接收引擎向事件引擎發(fā)送數(shù)據(jù)接收確認事件，由事件引擎根據(jù)ACK策略，立即通知發(fā)送引擎發(fā)送ACK信息或控制延遲ACK。最后，接收引擎生產(chǎn)數(shù)據(jù)到達中斷，通過接收接口發(fā)送至主機端。

■ 1.7 發(fā)送引擎

發(fā)送引擎面向數(shù)據(jù)流采用流水線模式設計TCP/IP協(xié)議發(fā)送處理流程，如圖7所示。

圖7 發(fā)送引擎實施框圖

發(fā)送引擎由事件驅(qū)動，事件源包括由發(fā)送接口傳遞的應用層數(shù)據(jù)發(fā)送事件、請求建立新連接事件、超時重傳事件等。發(fā)送引擎通過元數(shù)據(jù)加載模塊抽取事件參數(shù)構(gòu)建TCP Header、獲取緩存數(shù)據(jù)、進行Checksum計算、構(gòu)建IP數(shù)據(jù)報，最后通過物理鏈路接口發(fā)送[6]。

■ 1.8 FPGA 實現(xiàn)

TOE網(wǎng)絡協(xié)議棧系統(tǒng)在Xilinx Kcu115 FPGA板子上實現(xiàn)，該板子有四個10G網(wǎng)絡接口，4個4GB DDR4，網(wǎng)絡接口與TOE的工作頻率為156 25 MHz。資源使用見表1。

表1 資源使用表

2 驗證實驗

■ 2.1 實驗方法

為了驗證基于FPGA的TCP/IP協(xié)議卸載引擎的設計，搭建如圖8所示的實驗環(huán)境：兩臺陪試服務器分別安裝1塊Intel 82599ES 10G以太網(wǎng)卡，接入萬兆交換機；FPGA板安裝在一臺服務器，作為被試品接入萬兆交換機。在FPGA內(nèi)部實現(xiàn)Iperf3兼容程序，用于多并發(fā)Iperf測試，每次測試時間均為180s，測試次數(shù)為5次，取平均值。

圖8 實驗環(huán)境示意圖

■ 2.2 吞吐量實驗

在TOE接收路徑上，兩臺陪試服務器作為Iperf客戶端產(chǎn)生輸入壓力流量；在TOE發(fā)送路徑上，使用2臺陪試服務器機器作為Iperf服務端，使用FPGA產(chǎn)生發(fā)送流量，測試結(jié)果如圖9所示。

圖9 吞吐量實驗結(jié)果

從圖9可以看出，在接收路徑上，對于100個網(wǎng)絡連接，接收帶寬達到9 5GB/s，隨著連接數(shù)的增加，直到連接數(shù)達到1萬，接收帶寬穩(wěn)定在9GB/s左右；在發(fā)送路徑上，對于100個網(wǎng)絡連接，發(fā)送帶寬達到9 5GB/s，隨著連接數(shù)的增加，發(fā)送帶寬略有下降，連接數(shù)達到1萬時發(fā)送帶寬約為8GB/s，這主要是因為狀態(tài)管理器通過模塊讀寫鎖機制提供共享狀態(tài)表訪問服務，隨著連接數(shù)的增加，鎖競爭會帶來部分延時，但萬條并發(fā)連接，帶寬維持在8GB/s，仍然滿足數(shù)據(jù)中心常規(guī)使用場景。

吞吐量實驗結(jié)果表明，基于FPGA的TCP/IP協(xié)議卸載引擎的設計可以支撐高并發(fā)網(wǎng)絡連接場景，提供穩(wěn)定的高帶寬網(wǎng)絡吞吐量。

■ 2.3 延時實驗

如圖10所示為延時實驗的結(jié)果。由于網(wǎng)絡發(fā)送、接收路徑上的校驗和計算都需要存儲和轉(zhuǎn)發(fā)完整的數(shù)據(jù)段，因此延遲隨有效負載的大小而線性增加，實驗結(jié)果表明總體延時控制在3 5μs以內(nèi)。接收路徑上的延遲稍高，因為它需要哈希表和端口表查找，導致比發(fā)送路徑上更多的數(shù)據(jù)結(jié)構(gòu)訪問。

圖10 延時實驗結(jié)果

為了進一步減少延時，采用了兩種方式接收DDR旁路和TCP節(jié)點無延遲進行優(yōu)化，DDR旁路將片上RAM資源而不是DDR用于接收緩沖區(qū)，通過對比，可以將延時減少到0 5~1 6μs之間。同樣，使用TCP節(jié)點無延遲標志，即直接將有效負載不經(jīng)過DDR緩存而直接轉(zhuǎn)發(fā)到發(fā)送引擎，可以避免DDR內(nèi)存在發(fā)送路徑上的延遲。因此，延遲降低了0 3~1 5μs。忽略存儲和轉(zhuǎn)發(fā)的時鐘周期，帶有DDR旁路的接收路徑上的處理時間為恒定的85個周期，帶有TCP節(jié)點無延遲的發(fā)送路徑上的處理時間為70個周期，兩種優(yōu)化方式將延遲減少了近50%。

3 結(jié)束語

隨著網(wǎng)絡帶寬迅速增長以及數(shù)據(jù)規(guī)模的指數(shù)級增長，依賴操作系統(tǒng)內(nèi)核的TCP/IP網(wǎng)絡協(xié)議棧處理TCP/IP網(wǎng)絡通信流程的方式，導致網(wǎng)絡IO占用過多的處理器資源、網(wǎng)絡吞吐量受限、通信延時增加等問題。本文提出了一種基于FPGA的TOE設計方法，充分利用FPGA片上資源，采用狀態(tài)共享、通道分離的架構(gòu)，支持高并發(fā)連接場景，并能有效控制網(wǎng)絡延時。對基于FPGA實現(xiàn)的TOE網(wǎng)卡進行實驗驗證，結(jié)果表明：TOE網(wǎng)卡支持萬條TCP/IP網(wǎng)絡連接，網(wǎng)絡帶寬維持在較為穩(wěn)定的狀態(tài)，512字節(jié)的數(shù)據(jù)發(fā)送、接收網(wǎng)絡延時低于1μs。