実践的！FPGA開発セミナーvol.20 / FPGA_seminar_20_fixstars_corporation_20230329

by 株式会社フィックスターズ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright© Fixstars Group 本日のセミナーについて ● これまでのセミナーでは、 Vitis を使った UDP アプリケーションの作り方等を紹介してきました ○ 第2回: Vitis で FPGA ネットワーク通信を手軽に試すテクニック ○ 第10回: Vitis-AI 2.0 + Alveo で自前のカーネル + DPU で動かしてみた ● 今回のセミナーでは TCP を使ったアプリを作ってみます ○ TCP Oﬄoad Engine を Vitis から使うためのプロジェクトである EasyNet を用いて、FPGA 上に TCP Server を実装してみる ○ EasyNet と Vitis Libraries の gzip を組み合わせて、 gzip server を構築してみる

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright© Fixstars Group TCP Oﬄoad Engine (TOE) とは ● TCP のパケット処理機能をハードウェア上にオフロードしたもの ● TOE に (最低限) 必要な機能 ○ コネクション確立 ■ Server の場合 Port Listen, Client の場合 Connect など ○ パケットの順序制御・到達保護 ■ sequence 番号の付与・ack 送信 ■ checksum validation ○ アプリケーションとの通信 ■ connect, listen, close といったコネクション管理 API の提供 ■ send, recv といったデータ通信 API の提供

Slide 8

Slide 8 text

Copyright© Fixstars Group Xilinx FPGA 向けの TOE ● Xilinx FPGA 向けだと、以下のようなものが存在する ○ パートナー提供 ■ https://japan.xilinx.com/products/intellectual-property.html から toe で検索すると色々出てくる ○ オープンソース (HLS製、どちらも中身はほぼ同じ) ■ https://github.com/fpgasystems/fpga-network-stack ● BSD 3-Clause License ■ https://github.com/hpcn-uam/100G-fpga-network-stack-core/ ● BSD 3-Clause License ● Xilinx 公式の Vitis Network Example でも使用されている

Slide 9

Slide 9 text

Copyright© Fixstars Group fpga-network-stack ● https://github.com/fpgasystems/fpga-network-stack ● TOE 以外にも、TCP/IP 通信を実現するための機能が含まれている ○ Ethernet Header の parse/deparse ○ ARP による mac address の解決 (ARP Server) ○ ping による疎通確認 (ICMP Server) ○ UOE (UDP Oﬄoad Engine) ● 色々 IP が提供されているが、これを FPGA 上で動かすには Ethernet MAC, network stack, user function 等を繋ぐ必要がある ○ これが非常に面倒...

Slide 10

Slide 10 text

Copyright© Fixstars Group EasyNet ● FPL 2021 で提案された FPGA + TOE の評価環境 ○ https://ieeexplore.ieee.org/document/9556439 ○ source: https://github.com/fpgasystems/Vitis_with_100Gbps_TCP-IP ● オープンソースの network stack を Vitis 経由で簡単に利用できるようにしたもの ● 他にも MPI-like communication primitive とかも追加 (今回は未使用)

Slide 11

Slide 11 text

Copyright© Fixstars Group Vitis になるとどうして開発が楽になるのか？ ● 通常の FPGA 開発だと、ユーザは design top から全てを作る ○ ピン配置、top module, etc. ● Vitis による開発だとユーザはユーザロジックのみを作成すればよい (左図) ○ I/O 部分等はシェルとして事前に作成されている (ただしボードは固定) ● EasyNet の場合、シェルがネットワーク部分まで拡張したような形 (右図) ○ TCP を使うアプリケーションだけ FPGA に実装すればよい FPGA Shell xdma DDR Dynamic Region User Logic FPGA Shell xdma DDR Dynamic Region User Logic Ether mac NW stack EasyNet の提供するシェル

Slide 12

Slide 12 text

Copyright© Fixstars Group 参考: FPGA 開発における内部接続の比較 (主観) RTL IP Integrator Vitis 簡単さ × 〇〇柔軟性〇 △ × 実装の範囲回路全体回路全体ユーザロジックのみ内部の動作 - RTL code を出力 IP Integrator の接続を出力 RTL ● System Verilog 等で IP の接続を書く ● 記述量が多い ● generate 文とかは便利 ● design top から作る IP Integrator (右上図) ● GUI で IP を繋ぐので簡単 ● Intel の場合 Platform Designer相当 ● N 個回路を並べるとかが少し辛い ● design top から作る Vitis ● テキストで論理的な IP の接続を書く ● Intel の場合、 OneAPI, OpenCL など相当 ● ユーザロジックだけ作ればシェルと自動で繋がれる

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright© Fixstars Group EasyNet を動かしてみる ● EasyNet にはデフォルトでいくつかのユーザーカーネルが用意されている ○ iperf2 client/server ○ send kernel ○ recv kernel ○ gather kernel ○ all reduce kernel ● とりあえず iperf2 server を試してみる https://github.com/fpgasystems/Vitis_with_100Gbps_TCP-IP

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright© Fixstars Group チュートリアルデザイン (iperf) を動かしてみる (cont.) ● ビットストリーム書き込み後、下図の Host 1 から iperf2 を実行する ○ 1回目で合成失敗などもなく、普通に動いた ○ i7-9700 環境で MTU=9000 時に 89.2 Gbps => 十分な性能 ■ MTU=1500 時は 21.5 Gbps ● Xeon Gold 6234 でスレッド数が多ければ 100 Gbps 近く出るらしい Host 1 NIC Host 2 Alveo U250 100G cable

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright© Fixstars Group GZip との接続 ● Vitis Libraries の xilGzipComp を使用して gzip 圧縮を行う ● 通常の AXIS Input と TUSER 付きの AXIS Output を持つ IP https://xilinx.github.io/Vitis_Libraries/data_compression/2022.1/source/L2/api_reference.html#xilgzipcomp

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright© Fixstars Group 余談: xilGzipComp 単体の性能 ● xilGzipComp だけのプロジェクトを作って性能を計ってみた ○ データセット: http://www.mattmahoney.net/dc/textdata.html よりダウンロードできる wikipedia のダンプ ■ 100MB, 1GB ○ 比較対象: i5-4460 CPU, gzip command (デフォルトオプション) ● 特に上限サイズもなさそうで、性能も十分速い圧縮サイズ圧縮時間 CPU 35 MB 4.605 sec FPGA 41 MB 0.765 sec 圧縮サイズ圧縮時間 CPU 309 MB 40.200 sec FPGA 365 MB 5.140 sec 100 MB 1 GB

Slide 27

Slide 27 text

Copyright© Fixstars Group EasyNet と gzip の接続 ● 下図のような形で簡単に接続できた (括弧内はコード行数) ○ Reader (186): Listen 開始、データ受信 ○ App Packetize (50): TCP 単位の TLAST をペイロード全体の TLAST に書き換える ■ 最初のパケットの先頭に全体の長さを入れて判別 ○ xilGzipComp: Vitis Libraries そのまま ○ Tcp Packetize (124): 圧縮後パケットを MTU 単位で分割する ○ Sender (99): データ送信 User Logic EasyNet Reader App Packetize xilGzip Comp Tcp Packetize EasyNet Sender

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright© Fixstars Group Tips: Vitis (Alveo) での ILA の使い方 ● Vitis だとコンパイルオプションで ila を簡単に追加可能 ○ --dk chipscope:app_packetize_1:M_AXIS ● 普通に Vivado で FPGA に繋ぐだけだと ila が見えなかったのでやり方を記載 ○ 基本的には https://docs.xilinx.com/r/en-US/ug1393-vitis-application-acceleration/Automated-S etup-for-Hardware-Debug の内容を実施すればよい

Slide 30

Slide 30 text

Copyright© Fixstars Group Tips: Vitis (Alveo) での ILA の使い方 (cont.) ● Alveo を搭載したマシンで次のコマンドを実行して hw_server を立ち上げる ○ debug_hw --xvc_pcie /dev/xfpga/xvc_pub.XX --hw_server ● 合成したマシンで次のコマンドで ltx を指定して vivado を立ち上げ ○ debug_hw --vivado --host --ltx_ﬁle ./_x/link/vivado/vpl/prj/prj.runs/impl_1/debug_nets.ltx ● こうすると、HW Manager の画面が自動的に立ち上がり、 ila でのデバッグが可能

Slide 31

Slide 31 text

Copyright© Fixstars Group まとめ ● EasyNet を使って TOE のシェルと gzip 回路を結合してみた ● 結果 ○ 合成時間が想定外に長かったため、全体は動かず... ● 所感 ○ お手軽に TOE を FPGA で触れるのはすごく良い ■ Vitis を使っているので実装はかなり簡単 ■ Vivado の GUI を使わなくて良いのが気軽で良い ■ このように色々な I/O を Vitis で触れるようになると楽でいいなーという感じ ○ 結局合成時間が開発時間以上にかかるので、大きなものを作るとこっちがボトルネック ■ TOE までシェルに入れてユーザーロジックのみ DFX で合成できれば良いのかも

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Copyright© Fixstars Group open-nic の FPGA design 概要 ● HOST - FPGA 間の通信は PCIe 経由で QDMA で行われる ● QSFP の制御は CMAC IP が使用されている ● ユーザーロジックを追加できる領域は 2 箇所 (左図の灰色部) ● CMAC のポート数や QDMA の physical function の実装数などをパラメータ設定可能 FPGA design 全体図 (githubのREADMEから抜粋) 引用元：https://github.com/Xilinx/open-nic-shell

Slide 38

Slide 38 text

Copyright© Fixstars Group 性能確認環境 HOST 1 (Ubuntu 20.04.4 LTS) HOST 2 (Ubuntu 22.04.1 LTS) Alveo U250 (192.168.10.1) ConnectX-5 (192.168.10.2) 100Gbps DACケーブル ● iperf で throughput を測定した ● 並列数を 8 で実行 (確保される queue が 8 本だったため) ● open-nic 側を server / client の各々で実行 ● 今回は「高速化 = throughput を上げる」の意味で使用

Slide 39

Slide 39 text

Copyright© Fixstars Group open-nic の性能確認確認 open-nic (@client) open-nic (@server) throughput [Gbps] 21.6 4.12 ● open-nic を iperf の server として実行した場合の性能が低い ● Receive 側の方が負荷が大きく、性能が下がりやすいのは一般的 ● Mellanox NIC(ConnectX-5) でも RSS (Recieve Side Scaling) などの対策が取られている

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright© Fixstars Group open-nic の RSS の動作確認 ● open-nic は RSS (Recieve Side Scaling) をサポートしている ● 仕組みは以下の通り 1. driver install 時に driver から FPGA の register に qid を順に書き込む 2. FPGA 側で Toeplitz で hash 値を計算し、結果を address として register から qid を読み出す /* inform shell about the function map */ val = (FIELD_SET(QDMA_FUNC_QCONF_QBASE_MASK, qbase) | FIELD_SET(QDMA_FUNC_QCONF_NUMQ_MASK, qmax)); onic_write_reg(hw, QDMA_FUNC_OFFSET_QCONF(func_id), val); /* initialize indirection table */ for (i = 0; i < 128; ++i) { u32 val = (i % qmax) & 0x0000FFFF; u32 offset = QDMA_FUNC_OFFSET_INDIR_TABLE(func_id, i); onic_write_reg(hw, offset, val); } open-nic-driver code 抜粋

Slide 42

Slide 42 text

Copyright© Fixstars Group open-nic の RSS の動作確認結果 ● 対向の Mellanox NIC から open-nic に 1000 回 ping を投げた結果を以下に示す ● 各 queue に概ね均等に割り振られている ● 割り付けられている core が偏っているのは driver で特にコントロールしていないからだと思われる ○ 今回実験している HOST が 4 core なのでその影響の可能性は十分考えられる $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 34: 128 0 0 0 PCI-MSI 524288-edge onic1s0f0-0 35: 114 0 0 0 PCI-MSI 524289-edge onic1s0f0-1 36: 0 136 0 0 PCI-MSI 524290-edge onic1s0f0-2 37: 0 0 0 142 PCI-MSI 524291-edge onic1s0f0-3 38: 117 0 0 0 PCI-MSI 524292-edge onic1s0f0-4 39: 0 124 0 0 PCI-MSI 524293-edge onic1s0f0-5 40: 0 0 127 0 PCI-MSI 524294-edge onic1s0f0-6 41: 0 0 0 143 PCI-MSI 524295-edge onic1s0f0-7 42: 0 0 0 0 PCI-MSI 524296-edge onic-user 43: 0 0 0 0 PCI-MSI 524297-edge onic-error データ用 MSI-X 用

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Copyright© Fixstars Group open-nic-driver の修正 (MTU 設定値を上げる) ● FPGA 側のボトルネックはなさそう ● open-nic-driver を変更して throughput の向上を試みる ● 始めに MTU を上げる ○ default だと open-nic-driver は MTU を設定できるようにはなっていないので、driver のコードを修正する必要がある

Slide 46

Slide 46 text

Copyright© Fixstars Group MTU 設定のための修正 1 ● netdev 構造体の max_mtu の値を設定する ○ default 値は 1500 になっている $ git diﬀ onic_main.c diﬀ --git a/onic_main.c b/onic_main.c index b0eb3b1..bb70614 100644 --- a/onic_main.c +++ b/onic_main.c @@ -217,6 +217,8 @@ static int onic_probe(struct pci_dev *pdev, const struct pci_device_id *ent) } priv->pdev = pdev; priv->netdev = netdev; + priv->netdev->max_mtu = 9000; + spin_lock_init(&priv->tx_lock); spin_lock_init(&priv->rx_lock);

Slide 47

Slide 47 text

Copyright© Fixstars Group MTU 設定のための修正 2 ● ip command などで MTU 設定時に呼び出される関数内で引数で MTU 値を更新する ○ open-nic の default だと以下のように関数だけ準備されているので追加する $ git diﬀ onic_netdev.c diﬀ --git a/onic_netdev.c b/onic_netdev.c index 7449092..0da634d 100644 --- a/onic_netdev.c +++ b/onic_netdev.c @@ -764,6 +764,7 @@ int onic_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) int onic_change_mtu(struct net_device *dev, int mtu) { netdev_info(dev, "Requested MTU = %d", mtu); + dev->mtu = mtu; return 0; }

Slide 48

Slide 48 text

Copyright© Fixstars Group MTU 設定のための修正 3 ● FPGAの合成を option を以下のように指定して実行 ● ここまで実行しても、 MTU は 4K までしか動作しなかった ○ 理由は driver 内で受信 queue の initialize 時に (packet size に関係なく) page size (4K) 分確保しているため ○ 単純に確保 size の数値を増やしてみたが効果がなかった ○ 上記のため iperf で MSS を 4000 にして性能を比較した vivado -mode batch -source build.tcl -tclargs -board au250 -max_pkt_len 9600

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Copyright© Fixstars Group open-nic-driver の改善 (QUEUE の数を増やせるか？) ● QUEUE の数は何段階か経て driver 内で最適化されるが、実質的には以下の関数で制限されている ● kernel の関数をたどると、最終的には hardware の register を読んで決定しているようで、software 的な変更は簡単ではなさそうだった vectors = pci_alloc_irq_vectors(priv->pdev, non_q_vectors + 1, vectors, PCI_IRQ_MSIX);

Slide 51

Slide 51 text

Copyright© Fixstars Group open-nic-dpdk ● open-nic が用意しているもう一つの driver ● 一般的に dpdk を使用すると kernel module の driver と比較してoverehead がなくなり、 buﬀer の size も拡大できそう ○ MTU の制約もなくなりそうだし、単純に速く動作すると期待できる引用元：https://www.ntt-tx.co.jp/column/dpdk_blog/190610/

Slide 52

Slide 52 text

Copyright© Fixstars Group open-nic-dpdk 結果 (動作まで至らず) ● open-nic-dpdk の github の手順通りに進めたが、Section 8 の bind が動作せず ● コードを追っていくと、lspci で得た Device が期待と異なっていてエラーになっていた ○ lspci で得られた結果は以下の通りだが、コードで期待してるのは実行時に引き渡す引数 (vﬁo-pci) ○ なぜか qdma_pf (Xilinx の qdma driver)が default で load されてしまい、いろいろ試したが解決に至らなかった $ lspci -vmmks 01:00.0 Slot: 01:00.0 Class: Memory controller Vendor: Xilinx Corporation Device: Device 903f SVendor: Xilinx Corporation SDevice: Device 0007 Module: qdma_pf open-nic-dpdk: https://github.com/Xilinx/open-nic-dpdk