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

（1.江南大學(xué) 物聯(lián)網(wǎng)工程學(xué)院，江蘇 無錫 214122；2.江南大學(xué) 人工智能與計算機(jī)學(xué)院，江蘇 無錫 214122；3.江蘇省模式識別與計算智能工程實驗室，江蘇無錫 214122）

0 概述

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

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

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

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

1 量化高頻交易

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

1.1 量化高頻交易困境

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

1.2 基于FPGA 的網(wǎng)絡(luò)解決方案

應(yīng)交易所要求，行情商的服務(wù)器架構(gòu)如圖1 所示，其中：主端口進(jìn)行正常的TCP/IP 連接，鏡像端口只進(jìn)行數(shù)據(jù)的監(jiān)聽與接收。由于交易所與行情商間的網(wǎng)絡(luò)通信傳輸內(nèi)容單一、方向固定，且按照固定頻率發(fā)送，因此僅需基礎(chǔ)TCP 通信功能即能滿足通信需求。與完整協(xié)議棧相比，TCP 協(xié)議的通信靈活性下降，可靠性不變，但通信效率得到極大提升。針對量化高頻交易應(yīng)用場景，本文提出一種領(lǐng)域?qū)Ｓ玫腡CP/IP 卸載引擎設(shè)計，在滿足功能的前提下簡化TCP 協(xié)議，將通信延遲極度降低的同時保持穩(wěn)定的帶寬，實現(xiàn)效能的最大化。

圖1 行情商服務(wù)器架構(gòu)Fig.1 Server architecture of quotes suppliers

2 領(lǐng)域?qū)Ｓ肨CP/IP 協(xié)議的設(shè)計與實現(xiàn)

TCP/IP 協(xié)議是因特網(wǎng)的基礎(chǔ)，包含應(yīng)用層、運(yùn)輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層5 個部分［18-20］，其架構(gòu)如圖2 所示。其中，5 層協(xié)議將網(wǎng)絡(luò)接口層細(xì)分為數(shù)據(jù)鏈路層和物理層，其余與4 層協(xié)議一致。

圖2 TCP/IP 協(xié)議的架構(gòu)Fig.2 Architecture of TCP/IP protocol

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

圖3 FPGA 端的整體架構(gòu)Fig.3 Overall architecture of FPGA end

2.1 CMAC 內(nèi)核

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

圖4 CMAC 內(nèi)核的架構(gòu)Fig.4 Architecture of CMAC kernel

2.2 TCP/IP 內(nèi)核

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

圖5 TCP/IP 內(nèi)核的架構(gòu)Fig.5 Architecture of TCP/IP kernel

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

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

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

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

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

2.3 TOE 模塊

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

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

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

通用TOE 模塊分為接收部分、發(fā)送部分、計時器部分、狀態(tài)控制部分、緩沖查找部分和緩沖存儲部分，具體結(jié)構(gòu)如圖6 所示。

圖6 通用TOE 模塊結(jié)構(gòu)Fig.6 Structure of general TOE module

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

1）僅SYN 標(biāo)志位有效的數(shù)據(jù)報，為客戶端發(fā)送的連接請求。

2）SYN 和ACK 標(biāo)志位有效的數(shù)據(jù)報，為服務(wù)器發(fā)送的確認(rèn)報文。

3）ACK 標(biāo)志位有效但不攜帶數(shù)據(jù)的數(shù)據(jù)報，為客戶端的確認(rèn)報文。

4）ACK 標(biāo)志位有效且攜帶數(shù)據(jù)的數(shù)據(jù)報，為數(shù)據(jù)報文。

5）FIN 和ACK 標(biāo)志位有效，為連接釋放報文。依據(jù)分類啟動對應(yīng)的狀態(tài)機(jī)模塊。

數(shù)據(jù)發(fā)送部分會在等待連接緩存中存放的數(shù)據(jù)達(dá)到MSS 字節(jié)后，就將其組裝為1 個TCP 報文段發(fā)送出去。初始窗口大小定義為10 MSS 字節(jié)，當(dāng)觸發(fā)擁塞控制機(jī)制后，將會被介紹到MSS 字節(jié)，直到所有的數(shù)據(jù)報被確認(rèn)。

鏡像TOE 模塊分為接收模塊、發(fā)送模塊和數(shù)據(jù)緩沖排序模塊3 個部分。具體結(jié)構(gòu)如圖7 所示，該模塊是針對鏡像端口的設(shè)計。

圖7 鏡像TOE 模塊結(jié)構(gòu)Fig.7 Structure of mirror TOE module

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

2.4 用戶自定義內(nèi)核

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

圖8 用戶自定義內(nèi)核的整體架構(gòu)Fig.8 Overall architecture of user defined kernel

3 基于OpenCL 的整體平臺設(shè)計與優(yōu)化

3.1 基 于OpenCL 的FPGA 開發(fā)

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

3.2 數(shù)據(jù)位寬優(yōu)化

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

3.3 AXI4-Stream 接口的使用

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

3.4 并行設(shè)計優(yōu)化

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

圖9 內(nèi)核數(shù)據(jù)流水化模型Fig.9 Kernel data pipeline model

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

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

圖10 內(nèi)核數(shù)據(jù)展開模型Fig.10 Kernel data unroll model

3.5 內(nèi)存架構(gòu)優(yōu)化

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

圖11 內(nèi)存架構(gòu)的優(yōu)化設(shè)計Fig.11 Optimized design of memory architecture

3.6 整體功能設(shè)計

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

圖12 本文TCP/IP 卸載引擎結(jié)構(gòu)Fig.12 Structure of TCP/IP offload engine in this paper

4 實驗與結(jié)果分析

4.1 實驗環(huán)境

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

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

4.2 實驗結(jié)果

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

圖13 實驗平臺的架構(gòu)Fig.13 Architecture of experiment platform

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

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

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

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

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

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

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

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

4.3 存儲速率的測試與分析

本文針對HBM 和DDR 通道進(jìn)行速率測試，分別測試了主機(jī)端PCIE 與HBM 的速率，以及FPGA上每個內(nèi)核與HBM 和DDR 的速率，測試方式參照Xilinx 的Xbtest 架構(gòu)，統(tǒng)一使用256 MB 大小的數(shù)據(jù)包，測試結(jié)果如表3 所示。

表3 內(nèi)存讀寫速率對比Table 3 Comparison of memory read and write rates

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

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

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

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

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

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

4.5 與其他方法的對比

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

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

5 結(jié)束語

本文提出一種領(lǐng)域?qū)Ｓ玫脱舆t高帶寬TCP/IP協(xié)議棧，并在TCP/IP 協(xié)議卸載引擎架構(gòu)的基礎(chǔ)上將其嵌入Vitis 開發(fā)框架中。采用模塊化設(shè)計，各模塊使用相同規(guī)范的接口，開發(fā)人員只需按照接口規(guī)范封裝自定義模塊即可實現(xiàn)對網(wǎng)絡(luò)功能的自主配置和調(diào)用。通過優(yōu)化數(shù)據(jù)位寬設(shè)置固定MSS，優(yōu)化內(nèi)核和HBM 間的存儲效率，使用AXI4-Stream 接口優(yōu)化內(nèi)核間的傳輸效率。此外，使用數(shù)據(jù)流優(yōu)化和數(shù)據(jù)展開方式形成流水線型架構(gòu)，使整體性能達(dá)到最優(yōu)，并針對高頻交易場景設(shè)計一種鏡像TOE 模式。實驗結(jié)果表明，與傳統(tǒng)Linux+NIC 相比，該方法傳輸效率提升了12 倍，且獲得了更穩(wěn)定的傳輸波動。下一步將著重于完善TCP 協(xié)議的功能，增加最大連接數(shù)及對巨型幀的支持，并針對更多應(yīng)用場景開發(fā)專用型TOE 模塊，從而達(dá)到TCP 協(xié)議的傳輸效率最大化。