基于FPGA的TCP/IP協議卸載引擎設計

楊陽，周思遠，王舒鵬

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

0 引言

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

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

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

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

1 設計與實現

■ 1.1 系統架構

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

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

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

圖1 TCP/IP協議卸載引擎設計框架圖

■ 1.2 緩存控制

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

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

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

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

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

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

(6)ACK：ACK號；

(7)Transmitted： 已發送指針，標識已經被發送尚未被確認的數據尾部地址；

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

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

圖2 發送緩存示意圖

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

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

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

(3)Producer：生產者指針，標識接收數據的尾部地址；

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

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

(6)Length:亂序段長度；

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

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

圖3 接收緩存示意

■ 1.3 連接狀態管理

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

圖4 TCP狀態管理器實施框圖

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

■ 1.4 計時器

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

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

■ 1.5 事件引擎

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

圖5 事件引擎設計框圖

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

■ 1.6 接收引擎

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

圖6 接收引擎實施框圖

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

■ 1.7 發送引擎

發送引擎面向數據流采用流水線模式設計TCP/IP協議發送處理流程，如圖7所示。

圖7 發送引擎實施框圖

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

■ 1.8 FPGA 實現

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

表1 資源使用表

2 驗證實驗

■ 2.1 實驗方法

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

圖8 實驗環境示意圖

■ 2.2 吞吐量實驗

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

圖9 吞吐量實驗結果

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

吞吐量實驗結果表明，基于FPGA的TCP/IP協議卸載引擎的設計可以支撐高并發網絡連接場景，提供穩定的高帶寬網絡吞吐量。

■ 2.3 延時實驗

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

圖10 延時實驗結果

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

3 結束語

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