領域專用低延遲高帶寬TCP/IP 卸載引擎設計與實現

馮一飛，丁 楠，葉鈞超，柴志雷，3

（1.江南大學 物聯網工程學院，江蘇 無錫 214122；2.江南大學 人工智能與計算機學院，江蘇 無錫 214122；3.江蘇省模式識別與計算智能工程實驗室，江蘇無錫 214122）

0 概述

隨著網絡帶寬飛速增長，網絡傳輸占用的CPU資源正逐年上升。以24 核計算型服務器為例，網絡傳輸在25 GB 網絡環境下占用CPU 資源的25%；當升級到100 GB 網絡時，CPU 資源將被100%占用，導致算力資源嚴重缺乏［1-2］。此外，傳統軟件處理網絡堆棧的方式存在吞吐率低、毫秒級別的套接字機制和軟件處理延遲等問題，且由于CPU 的主頻動態調整機制、操作系統的進程調度等因素，導致延遲具有不穩定性［3］，使得基于CPU 的軟件方案難以應用于高頻通信傳輸等對延遲敏感的場景［4］。

在后摩爾時代，CPU 頻率已趨于穩定，計算能力增速遠低于網絡傳輸速率的增速，且差距持續增大［5］，預計至2025 年，算力差距將大于60 Gb/s［6］。因此，將網絡協議等計算任務卸載到現場可編程門陣列（Field Programmable Gate Array，FPGA）等硬件的需求愈發急迫。隨著市場規模不斷擴大，各種應用場景不斷出現，且在特定場景中不需要完整的傳輸控制協議/互聯網協議（Transmission Control Protocal/Interner Protocal，TCP/IP）協議棧，這為采用純硬件提供了可行性。如在量化高頻交易場景下［7］，僅需TCP 協議中數據收發、重排等基礎功能即可滿足通信功能需求。因此，領域專用TCP/IP協議與硬件加速相結合成為解決特定場景帶寬和延遲問題的有效手段。

文獻［8］提出一種針對高頻交易的基礎網絡實現方案，使用高級合成（High-Level Synthesis，HLS）開發語言對UDP 協議進行實現，在配合交易算法的情況下，能使延遲小于870 ns。文獻［9］提出一種基于SDAccel 開發的系統，使用HLS 實現了10 Gb/s TCP 協議和IP 協議的功能。文獻［10］針對量化高頻交易中的訂單查詢功能，使用VHDL 開發語言進行實現，最低延遲為253 ns。文獻［11］提出一種基于總線的市場數據解碼引擎設計，針對不同的市場數據模板，使用HLS 實現一種自動構建解碼引擎的結構，平均延遲為1.3 μs。

傳統的FPGA 開發方式以Verilog 等HDL 硬件開發語言為主，存在修改不便且開發周期長的問題。本文在Vitis 開發架構下［12］結合使用開放運算語言（Open Computing Language，OpenCL）和高層次綜合HLS 進行開發，以大幅縮短開發周期，便于開發人員修改。同時，針對量化高頻交易場景，在滿足功能的條件下優化性能。

1 量化高頻交易

近年來，量化高頻交易（Quantitative High-Frequency Trading，QHFT）在不斷改變金融市場結構。作為一種新型投資策略，量化高頻交易通過快速買賣股票獲取利潤，持有時間通常以秒或毫秒為單位［13］。量化高頻交易在美國股票市場的占比很大，截止2019年，高頻交易占美國股票訂單量的83%，占美國股票交易總額的70%以上［14］，歐洲市場規模類似［15］，國內市場起步相對較晚，但也展現出勃勃生機［16］。

1.1 量化高頻交易困境

以微秒為單位的量化高頻交易的主要困境在于網絡通信部分，在瞬息萬變的金融交易市場中，行情商獲取的行情信息延時越低，意味著有越多的交易機會和更大的決策空間［17］。傳統軟件處理網絡的方式存在高延遲、高占用、帶寬利用率低、延遲不穩定等問題，而采用純硬件實現網絡通信功能具有低延遲、高帶寬、固定延遲等特點，符合行情商的期望。

1.2 基于FPGA 的網絡解決方案

應交易所要求，行情商的服務器架構如圖1 所示，其中：主端口進行正常的TCP/IP 連接，鏡像端口只進行數據的監聽與接收。由于交易所與行情商間的網絡通信傳輸內容單一、方向固定，且按照固定頻率發送，因此僅需基礎TCP 通信功能即能滿足通信需求。與完整協議棧相比，TCP 協議的通信靈活性下降，可靠性不變，但通信效率得到極大提升。針對量化高頻交易應用場景，本文提出一種領域專用的TCP/IP 卸載引擎設計，在滿足功能的前提下簡化TCP 協議，將通信延遲極度降低的同時保持穩定的帶寬，實現效能的最大化。

圖1 行情商服務器架構Fig.1 Server architecture of quotes suppliers

2 領域專用TCP/IP 協議的設計與實現

TCP/IP 協議是因特網的基礎，包含應用層、運輸層、網絡層、數據鏈路層和物理層5 個部分［18-20］，其架構如圖2 所示。其中，5 層協議將網絡接口層細分為數據鏈路層和物理層，其余與4 層協議一致。

圖2 TCP/IP 協議的架構Fig.2 Architecture of TCP/IP protocol

本文采用模塊化設計原則，將TCP/IP 協議中不同的功能分離成不同的模塊。FPGA 端分為CMAC內核、TCP/IP 內核和用戶自定義內核3 部分，具體架構如圖3 所示。CMAC 內核將接收到的光信號轉換為電信號數據并傳輸給TCP/IP 內核，TCP/IP 內核將數據報解析后發送至用戶自定義內核處理。

圖3 FPGA 端的整體架構Fig.3 Overall architecture of FPGA end

2.1 CMAC 內核

CMAC 內核包含1 個10 GB/25 GB 高速以太網子系統（High Speed Ethernet Subsystem，HSES）［21］的IP 核模塊。該IP 核模塊采用IEEE 802.3 標準，包含完整的以太網MAC 及物理編碼子層/物理介質連接（Physical Coding Sublayer/Physical Medium Attachment，PCS/PMA）功能，可以在每塊FPGA開發板上進行單獨配置，極大提升網絡協議在不同FPGA開發板間的可移植性。該IP 模塊將整個計算平臺基礎架構與GT 引腳相連，GT 引腳指向QSFP28 網絡接口，與外部網絡進行數據通信。CMAC內核可以根據實際應用需求，配置為10 GB和4×10 GB 兩種模式。CMAC 內核和TCP/IP 內核間通過AXI4-Stream 接口相連，用于接收和發送網絡數據包，CMAC 內核的具體架構如圖4 所示。

圖4 CMAC 內核的架構Fig.4 Architecture of CMAC kernel

2.2 TCP/IP 內核

TCP/IP內核包含TCP卸載引擎（TCP Offload Engine，TOE）模塊、UDP 模塊、IP 模塊、ICMP 模塊和ARP 模塊，所有模塊均使用HLS 進行實現，模塊之間使用64 位AXI4-Stream 接口連接。該內核支持最大64 個并發TCP 連接，每個連接提供32 KB 的buffer作為發送和接收的緩沖區。TCP/IP 內核的整體架構如圖5 所示。

圖5 TCP/IP 內核的架構Fig.5 Architecture of TCP/IP kernel

由圖5 可知，TCP/IP 內核的各功能模塊均封裝為單獨的IP 核，可以依據應用場景、板卡資源等因素進行選擇性配置。針對量化高頻交易等特殊應用場景，本文開發出一種類TCP 協議解決此類問題。與CMAC 內核相同，TCP/IP 內核暴露出固定的接口，供開發人員調用。

IP 模塊包含IP 接收和IP 發送2 個部分，支持IPV4 協議，可以通過主機端設置固定的IP 地址、子網掩碼和網關地址。IP 接收部分會首先判別協議類型，丟棄IP 和ARP 以外的數據包，同時將ARP 數據包轉發至ARP 模塊。之后對IP 幀包進行首部校驗和檢查以及上層協議類型檢查，將數據部分轉發至對應上層模塊。發送模塊同樣對ARP 和IP 模塊進行分開處理，并計算IP 幀的首部校驗，將數據部分與頭部封裝后發送給CMAC 內核。

ARP 模塊包含ARP 請求的發送和接收功能以及ARP 響應的發送和接收功能。ARP 映射表放在BRAM 內，最多能同時保存128 組映射關系。在發出ARP 請求后，會在映射表中保留500 ms，若仍未收到ARP 響應，則會被刪除并標記為未答復的請求。

ICMP 模塊包含接收回送請求報文和發送回送回答報文的功能，會對接收到的ICMP 幀進行校驗、檢測和計算，并封裝為回送回答報文，傳輸至IP 發送部分。

UDP 模塊包含報文的接收和發送功能，通過主機端來設置目的IP 地址、目的端口和源端口。UDP模塊在作為接收端時支持最大64 KB 可編程監聽端口，對于無效數據將直接舍棄，且能夠進行校驗和計算，將解析后的數據傳輸給自定義模塊；在作為發送端時，會先添加偽首部計算校驗和，之后封裝為UDP幀，傳輸給IP 協議。

2.3 TOE 模塊

針對不同的需求，TOE 模塊開發出以下2 種TCP 變體協議模塊：

1）通用TOE 模塊。針對量化高頻交易中主端口設計，建立正常的握手連接、支持發送和接收功能，實現TCP 擁塞控制，包括擁塞避免、快速重傳等；

2）鏡像TOE 模塊。針對量化高頻交易中交換機的鏡像端口開發，只實現TCP 數據報的接收功能和數據重排功能，并將解析出的數據部分傳輸給上層用戶自定義內核。2 種模塊均為每個TCP 連接提供了32 KB 大小的buffer 作為數據緩沖區。鏡像TOE模塊能夠接收的最大報文長度為MSS 字節，不支持對巨型幀的接收。

通用TOE 模塊分為接收部分、發送部分、計時器部分、狀態控制部分、緩沖查找部分和緩沖存儲部分，具體結構如圖6 所示。

圖6 通用TOE 模塊結構Fig.6 Structure of general TOE module

由圖6 可知，接收部分會先對TCP 數據報進行解析，解析后的數據報依據TCP 首部分為以下5 種：

1）僅SYN 標志位有效的數據報，為客戶端發送的連接請求。

2）SYN 和ACK 標志位有效的數據報，為服務器發送的確認報文。

3）ACK 標志位有效但不攜帶數據的數據報，為客戶端的確認報文。

4）ACK 標志位有效且攜帶數據的數據報，為數據報文。

5）FIN 和ACK 標志位有效，為連接釋放報文。依據分類啟動對應的狀態機模塊。

數據發送部分會在等待連接緩存中存放的數據達到MSS 字節后，就將其組裝為1 個TCP 報文段發送出去。初始窗口大小定義為10 MSS 字節，當觸發擁塞控制機制后，將會被介紹到MSS 字節，直到所有的數據報被確認。

鏡像TOE 模塊分為接收模塊、發送模塊和數據緩沖排序模塊3 個部分。具體結構如圖7 所示，該模塊是針對鏡像端口的設計。

圖7 鏡像TOE 模塊結構Fig.7 Structure of mirror TOE module

由圖7 可知，在接收到TCP 數據報后，由于鏡像接口不需要也無法進行握手協議的建立，鏡像TOE模塊會直接對其進行解析，若不攜帶數據部分，則直接舍棄。在緩沖區，數據部分將被按照序列號保存為5 組數據，并被進行排序設計。發送模塊與UDP協議類似，先添加偽首部計算校驗和，之后封裝為TCP 協議數據報傳輸給IP 模塊。鏡像TOE 模塊設計也可用于FPGA 片間通信。

2.4 用戶自定義內核

在用戶自定義內核中，用戶能夠依據應用場景需求，設計對應硬件加速模塊，通過預設的接口，處理從網絡中接收到的數據，同時將處理完的數據通過網絡發送出去。該內核與TCP/IP 內核中的UDP模塊和TOE 模塊通過AXI4-Stream 接口相連，同時通過XDMA 與主機端進行數據交互。用戶自定義內核的整體架構如圖8 所示，該模塊提供了一個量化高頻交易中FAST 解碼協議的硬件實現，并作為對整體網絡通信的功能性驗證。依據上海證券交易所的FAST 協議規范，設計實現3 201 逐筆成交模板和5 801 逐筆委托模板中無運算符、常量、復制、缺省和自增5 種操作，接收從鏡像TOE 模塊傳輸來的數據，并進行處理，將結果傳輸回主機端，方便后續數據的金融決策計算。

圖8 用戶自定義內核的整體架構Fig.8 Overall architecture of user defined kernel

3 基于OpenCL 的整體平臺設計與優化

3.1 基 于OpenCL 的FPGA 開發

Vitis是目前最先進的FPGA開發框架之一［22］，用戶可以通過調用OpenCL API 來管理Xilinx 運行時庫（Xilinx Runtime Library，XRT）與硬件加速器部分的交互。Vitis 提供3 種對FPGA 內核的調度模式：順序執行模型、流水線模型和自由運行模型［23］。由于TCP/IP 協議使用監聽機制，因此本文采用自由運行模型的調度機制，當FPGA 從主機或其他內核接收流式數據時，便會對數據進行處理，當沒有數據時，則會自動停止運行。

3.2 數據位寬優化

在整體設計中，為保持網絡4×10 Gb/s 的傳輸速率，主要瓶頸在于網絡內核模塊和內存之間的數據交互。在TCP/IP 內核中，數據部分會暫時存儲在內存中，起到重新傳輸或緩沖目的。從理論上來說，若想達到4×10 Gb/s 的帶寬效率，則需要至少40 Gb/s的內存帶寬。Vitis 開發架構針對64 Byte 對齊的順序內存訪問提供了優化，若使用未對齊的內存訪問，則會顯著減少內存帶寬，因為在這種情況下，網絡將觸發自動對齊的內存訪問。對于每個TCP/IP 連接，在建立時均會分配一個初始內存地址，并在初始內存地址的偏移量中存儲即將到來的數據報。初始內存地址在連接建立時確定，有很大幾率不是64 Byte對齊。同時，在默認的TCP/IP 設置中，MSS 為1 460 Byte，并非64 Byte 的倍數。結合應用場景下實際網絡的傳輸情況，網絡設備通常傾向于發送較短數據報，以最大程度提高網絡利用率。因此針對上述2 個問題，本文將初始內存地址默認為0，同時將MSS 降低為1 408 Byte，這是比1 460 小且為64 Byte 的最大倍數。每個連接的偏移內存均固定為1 408 Byte，故定義初始內存地址的物理偏移量為64 Byte 的整數倍，以此降低網絡內核模塊和內存之間的讀取延遲。

3.3 AXI4-Stream 接口的使用

Vitis 開發架構支持使用AXI4-Stream 流接口來完成內核之間的數據傳輸，本設計中各個模塊間均使用AXI4-Stream 接口。使用流接口進行開發的優勢在于內核之間可以直接進行數據流式傳輸，相當于申請一個無限深度的FIFO，而不必通過全局內存進行數據傳輸，能夠顯著提升傳輸性能。在Vitis 開放框架下，必須使用AXI4-Stream 接口才能使用自由運行模型，各模塊在接收到數據的同時，便可進行處理，不需要主機端的控制信號，從而提升數據傳輸處理效率。

3.4 并行設計優化

并行優化設計主要通過數據流優化、數據展開等來提升整體設計的并行度。數據流優化即對規模較大的組合邏輯進行分級處理，在各級之間添加寄存器暫存中間數據，通過消耗一定的寄存器資源實現任務級流水，以達到更高的吞吐量和更低的延遲。TCP/IP 各層協議間以及每層協議內的數據均沒有數據依賴性，因此可以進行流水線設計。以IP 接收模塊的實現為例，流水化設計如圖9 所示。

圖9 內核數據流水化模型Fig.9 Kernel data pipeline model

由圖9 可知，該模塊可以簡化為接收數據、校驗和計算、解析數據和轉發數據4 個部分，假設每部分的時間消耗為1 個時鐘周期，未使用數據流優化時，每組計算消耗4 個時鐘周期，在使用數據流優化之后，除去首次延遲外，每組計算只消耗1 個時鐘周期。其他模塊也采用相同的流水型設計，以最大程度地縮短整體平臺的執行時間。

數據展開通過增加并行度來縮短數據延遲。以TCP/IP 協議中常用的校驗和計算為例，數據以64 Byte 流輸入，將其全展開，分為4 個16 Byte 的數據，并分別進行累加和移位運算，減少校驗和計算的時間開銷，內核數據展開模型如圖10 所示。由圖10 可知，當未使用數據展開時，執行校驗和計算需要11 個時鐘周期完成；在使用數據展開后，只需2 個時鐘周期便可完成，可見數據展開能夠大幅縮短數據延遲。

圖10 內核數據展開模型Fig.10 Kernel data unroll model

3.5 內存架構優化

在Vitis 框架下，主機端和FPGA 端通過全局內存進行數據交互。在默認情況下，Vitis 自動把全部計算單元（Computing Unit，CU）連接到同一全局內存，這導致每次只有一個內核可以和全局內存進行讀寫數據，這限制了整體平臺的性能。本文對內存架構進行優化，將CU 鏈接至不同的HBM 偽通道（Pseudo Channels，PC）單元，同時設置CU 和內存到同一塊超級邏輯區域（Super Logic Regions，SLR）［24］上，以最大化帶寬的使用。以用戶自定義內核為例，該模塊有4 個返回值，通過將其分配在和SLR 0 相連的HBM 0 的4 個PC 單元中，可將傳輸速率提升為之前的4 倍。內存架構的優化設計如圖11 所示。由圖11可知，雖然每PC 單元的傳輸性能為14.3 Gb/s，低于DDR 通道的傳輸性能19.2 Gb/s，但是可以通過內存架構的優化，實現對多PC 的訪問連接，從而達到提高總體傳輸效率的目的。此方法在Xilinx Alevo系列和Intel Stratix V 系列板卡上均有較好的適用性。

圖11 內存架構的優化設計Fig.11 Optimized design of memory architecture

3.6 整體功能設計

如圖12 所示為本文TCP/IP 引擎結構，其主要分為主機端和FPGA 端2 大部分。其中：主機端負責與OpenCL 程序外部的交互、與FPGA 端的數據交互及內核部分的調度與管理；FPGA 端負責TCP/IP 協議及后續數據加速模塊的實現。FPGA 端包含CMAC 內核、TCP/IP 內核以及用戶自定義內核3 個模塊。其中，在TCP/IP 內核中，用戶可以通過量化高頻交易中的不同場景進行自由配置。在上述3個模塊間使用AXI4-Stream接口進行數據交互，通過使用數據對齊來降低數據模塊和內存之間的數據延遲。針對TCP/IP 協議各功能模塊及校驗和計算間無數據關聯性的特點，采用數據流優化和數據展開優化形成流水線并行架構，同時對內存架構進行優化，降低內核和主機端間的數據傳輸延遲。

圖12 本文TCP/IP 卸載引擎結構Fig.12 Structure of TCP/IP offload engine in this paper

4 實驗與結果分析

4.1 實驗環境

本文的軟件環境為Centos Linux release 7.7.1908，Vitis 的版本為2021.1，XRT 版本為202110.2。硬件環境為2張XilinxAlveo U50數據中心FPGA加速卡、Intel i9-9900x 的CPU 及華為S5720-28X-LI-AC 交換機。該款FPGA加速卡擁有872 KB的LUTs、8 GB的HBM和1個QSFP28網絡接口。其中，QSFP28網絡接口支持10 GB、25 GB、40 GB、100 GB、4×10 GB 和4×25 GB 的網絡配置。使用PCIE Gen 3×16 和服務器連接，支持Vitis 開發平臺通過Gen 3×16 XDMA 進行開發。FPGA 加速卡的資源配置如表1 所示。

表1 FPGA 加速卡的資源配置Table 1 Resource configuration of FPGA accelerator card

4.2 實驗結果

本文整體實驗平臺搭建如圖13 所示。由圖13可知，在FPGA 平臺中例化3 組MAC 層和IP 層IP核，即3 個IP 地址，并分別和UDP、通用TOE、鏡像TOE 這3 個模塊直連，各模塊間可同時使用10 GB SFP+光口與交換機通信。本設計全局使用300 MHz時鐘，內核的延遲數通過在硬件內部構件（Intergrated Logic Analyzers，ILA）進行統計，和時鐘相乘獲得延遲時間。

圖13 實驗平臺的架構Fig.13 Architecture of experiment platform

整體平臺的資源消耗如表2 所示，LUTS 消耗超過5 成，DSP 的使用率很低。其中基礎網絡平臺部分的LUTS 和FIFO 的資源占用率都未超過10%，為后續加速程序開發留出充足的資源。

表2 計算平臺的FPGA 消耗Table 2 FPGA consumption of computing platform

本文網絡計算平臺在UDP、通用TOE 和鏡像TOE 這3 種通信協議下的通信延遲如圖14 所示。測試使用100 Byte 的數據，由Host 端按照UDP 協議和TCP 協議發出，發送至UDP 通信協議和通用TOE 通信協議對應的IP 地址，同時設置交換機鏡像接口并將數據發送至鏡像TOE 模塊。在FPGA 端，UDP 和鏡像TOE 協議的延遲幾乎一致，在量化高頻交易應用場景下有極大的使用空間。

圖14 3 種通信協議的通信延遲Fig.14 Communication delay of three communication protocols

將MAC 中的輸出端口和接收端口通過Loopback IP 核回環起來，測試數據包的生成和吞吐量的測試也在FPGA 端完成。理想的吞吐量T可以通過式（1）計算獲得：

其中：P為發送的數據包長度；H為首部長度。根據式（1）可得，采用較大的P可以提高網絡的吞吐量。UDP 協議下的首部總長度為28 Byte，TCP 協議下的首部總長度至少為50 Byte，因此使用UDP 協議在理論上可以獲得更高的吞吐率。圖15 顯示了不同通信協議下P與吞吐率間的關系。

圖15 4 種通信協議的吞吐量對比Fig.15 Comparison of throughput of four communication protocols

由圖15 可知，UDP 協議的吞吐量最高，可以達到9.57 Gb/s，兩種TOE 模式也分別能達到9.36 Gb/s和9.42 Gb/s，QSFP28 光口的本質為4 路SFP+接口的疊加，因此3 種模式可以分別接入不同的GT 實現并行運行，最大吞吐量可達38.28 Gb/s。

4.3 存儲速率的測試與分析

本文針對HBM 和DDR 通道進行速率測試，分別測試了主機端PCIE 與HBM 的速率，以及FPGA上每個內核與HBM 和DDR 的速率，測試方式參照Xilinx 的Xbtest 架構，統一使用256 MB 大小的數據包，測試結果如表3 所示。

表3 內存讀寫速率對比Table 3 Comparison of memory read and write rates

由表3 可知，主機端至HBM 的速率最低，因此在設計加速程序時，除必要數據外，應盡量減少FPGA 和主機端間的數據傳輸。雖然HBM 上單個PC 的傳輸速率低于DDR，但是同時訪問4 個PC 的速率遠大于DDR 的訪問速率。通過對內存架構進行優化，將內核中不同數據塊進行分離，每個輸出都使用單獨的AXI 口與不同的PC 相連，實現對多PC的訪問，以大幅提升訪存速度。

4.4 整體通信功能的驗證與分析

為驗證TCP/IP 引擎設計的整體功能完備程度，以及對量化高頻交易的支持度，本文從主機端發送不同數量1 408 Byte 大小的上交所逐筆成交PCAP數據包，使用ILA 測試鏡像TOE 模塊下，從數據接收到FAST 協議解析的平均時間延遲，同時測試Linux環境下使用10 GB 網卡接收數據包并解析的平均時間延遲，結果如圖16 所示。由圖16 可知，Linux 搭配網卡的平均延遲在120 μs～200 μs 之間，受CPU 的波動影響較大，TOE 模式下平均延遲穩定在9.5 μs 左右，時間固定、無波動，此外，TOE 模式下的延遲縮短到軟件方案的1/12。

圖16 通信延遲對比Fig.16 Comparison of communication delay

本文對在Xilinx Alveo U50 數據中心上實現的網絡通信和FAST 解碼協議的穿透延遲進行了測算，包含從MAC 層進入，經過IP 層和鏡像TOE 的解析，傳輸至FAST 協議模塊解碼的數據處理總延遲。各部分的延遲如表4 所示。由表4 可知，針對FAST 解碼協議的通信延遲最低可至677.9 ns。在鏡像TOE 模塊下，網絡部分的延遲最低為468.4 ns，可以滿足高頻通信應用場景的需求。

表4 FAST 協議穿透延遲測試結果Table 4 Penetration delay test result of FAST protocol ns

4.5 與其他方法的對比

表5 所示為不同方法的對比，方法1［4］、方法2［5］、方法3［8］、方法4［9］、方法5［14］皆在FPGA 上實現了TCP/IP功能。本文在Vitis 框架下，使用HLS 進行開發，通過數據位寬優化、內核存儲優化以及數據流優化，實現了TCP/IP 引擎。與使用Verilog/VHDL 等開發語言的實現方案相比，本文方法開發周期短，便于修改，開發人員可以依據經濟、政治等因素快速在自定義模塊中對量化高頻交易政策作出調整，同時本文方法的最大吞吐率達38.28 Gb/s，最低通信延遲為468.4 ns，取得了效能的最優解。

表5 不同方法的對比Table 5 Comparison of different methods

5 結束語

本文提出一種領域專用低延遲高帶寬TCP/IP協議棧，并在TCP/IP 協議卸載引擎架構的基礎上將其嵌入Vitis 開發框架中。采用模塊化設計，各模塊使用相同規范的接口，開發人員只需按照接口規范封裝自定義模塊即可實現對網絡功能的自主配置和調用。通過優化數據位寬設置固定MSS，優化內核和HBM 間的存儲效率，使用AXI4-Stream 接口優化內核間的傳輸效率。此外，使用數據流優化和數據展開方式形成流水線型架構，使整體性能達到最優，并針對高頻交易場景設計一種鏡像TOE 模式。實驗結果表明，與傳統Linux+NIC 相比，該方法傳輸效率提升了12 倍，且獲得了更穩定的傳輸波動。下一步將著重于完善TCP 協議的功能，增加最大連接數及對巨型幀的支持，并針對更多應用場景開發專用型TOE 模塊，從而達到TCP 協議的傳輸效率最大化。