輪講資料: A Comprehensive Study on Off-path SmartNIC

研究室の輪講用

Wei, X., Cheng, R., Yang, Y., Chen, R., and Chen, H., “Characterizing Off-path SmartNIC for Accelerating Distributed Systems”, arXiv e-prints, 2022. doi:10.48550/arXiv.2212.07868.
Published at OSDI '23

Transcript

1. A Comprehensive Study on Off-path SmartNIC Xingda Wei, Rongxin Cheng, Yuhan Yang, Rong Chen, and Haibo Chen arXiv preprint 2212.07868 植松郁生 2023/5/27
2. 本論文のトピック • SmartNICの特徴 • Off-path SmartNICのネットワーク機能に注目した性能評価 • 性能低下を引き起こすシチュエーションに対するアドバイス
3. 1. Introduction & 2. Background and Context
4. RDMA / InfiniBandにおける補足 one-sided RDMA primitives (operations): • 片方向のメモリアクセス，送信側のみが受信側のメモリにアクセス • 具体的な通信: READ/WRITE • 単純でより高パフォーマンス • 受信側のCPUによる処理を必要としない two-sided RDMA primitives: • 双方向のメモリアクセス，送信側・受信側が相互にメモリアクセス • 具体的な通信: SEND/RECV • 受信側のCPUによる処理を必要とする • より通信を抽象化しており扱いやすい
5. RDMA / InfiniBandにおける補足 QP (Queue Pair): • TCP/IPにおけるsocketのような通信の端点 (アプリケーションとの接点) • Send/Receive Bufferの代わりにSend/Receive Queue (SQ/RQ) を持つ • SQ/RQの中にはそれぞれ送信/受信要求 WR (Work Request) がWQE (Work Queue Element) としてFIFOで積まれている CQ (Completion Queue): • QPの外部に設定されたFIFOのキュー • 各WQEの処理が完了するとCQE (Completion Queue Entry) としてFIFOでCQに 積まれる • ユーザ(CPU)はCQに対してポーリングすることでCQEを取り出し (WC: Work Completion)，WRの完了を知る • ただしこれはシグナルがついている要求の場合のみ，シグナルをつけず独自実装 で完了を通知させることもできる (要求の非シグナル化)
6. RDMA / InfiniBandにおける補足 サービスタイプ: • RDMA/InfiniBandにおけるトランスポート層 (TCP/IPにおけるTCP/UDPに相 当) • Reliable/UnreliableとConnection/Datagramの組み合わせで4種類が存在する • RDはユーザランドに提供されていないので，実質RC / UC /UDの3種類 • 通常よく使われるのはRC (TCPに相当) とUD (UDPに相当)
7. SmartNICとは？ RDMA-capable NIC (RNIC) • RDMAを扱えるNIC，低レイテンシかつ高帯域 • HW/SW両面での対応が必要 RNICの問題点 • ホストのCPU使用率が高くなる ，サチる • two-sided primitivesで問題に • 特に高帯域のネットワークを利用した分散システムで問題に • 例: NICコア単体では195Mppsの処理性能→two-sidedでは89Mppsまで落ちる • 通信量の増幅 • one-sided primitivesの場合，受信側のCPUを消費しない →複雑な処理はできない →複数回のアクセスが必要になり1リクエストあたりの通信量が増える • 例: key-valueストアへのアクセス
8. SmartNICとは？ SmartNIC (SNIC) • RNICの一種 • プログラム可能な機能を備えたもの • より複雑な計算をNICにオフロードできる • オフロードの仕方で2種類存在 • On-path SmartNIC: NIC – ホスト間のパイプラインでインラインに処理 • Off-path SmartNIC: NIC – ホスト間のパイプラインに外付け
9. SmartNICの種類 On-path SmartNIC • NICコアを低レベルAPIを利用してホストから制御 • NW処理パイプライン上でオフロードされた処理を実行 • NIC – ホスト間でのインラインで処理が必要なリクエストには有効 • 生のパケットを操作するため低レベルプログラミングが必要，開発の ハードル高い • オフロード処理とNW要求処理がNICコアで競合する
10. SmartNICの種類 Off-path SmartNIC • RNICとホストとの間にプログラマブルなSoCを置く • NICコア，SoC，ホストはPCIeスイッチで接続 • SoCはホスト同様の完全なOSが載ったサーバとして扱える • NWのクリティカルな部分は直接触らない，開発のハードル低い • オフロード処理とNW要求処理が競合しない • PCIeスイッチがボトルネックになる可能性がある
11. SmartNICに関する先行研究 • コンピューティング性能に焦点を当てたものが多い • Off-path SmartNICに載っているSoCはホストよりも性能が当然低い • ネットワーク自体の性能改善には至らないという結論になっていた • ネットワーク性能の向上につながる部分を考慮すべき • 単一のネットワーク経路だけでなく複数の経路を利用した場合など • ネットワーク性能に影響を及ぼしている要因も探るべき • SoC-ホスト間のRDMA通信についてももっと注目すべき
12. 本論文の特徴 様々なネットワーク経路に対して SmartNICのアーキテクチャが及ぼす影響について系統的に分析 • 経路毎のパフォーマンスの差異を分析 • 各経路におけるボトルネックの検討 • 特にSoCが関連するような経路にSoCが及ぼす影響 • 複数経路を同時に利用した場合に経路同士が相互に及ぼす影響
13. 今回扱うSmartNIC Mellanox Bluefield-2 ハードウエア: • Off-path SmartNIC • RNICであるConnectX-6をNICコアとして搭載 • 内部に2つのPCIeリンク • SoCはPCIeリンクを介さずPCIeスイッチに直結 • PCIeスイッチとSoCがどのように作用しているかは不明 (ドキュメントなし)
14. 今回扱うSmartNIC Mellanox Bluefield-2 ソフトウエア: • SoCは通常のARMサーバとして扱えるよう普通のLinuxが動作している • RDMA向けの完全なネットワークスタックがLinuxカーネル上で動作しており， ホストからオフロードされたタスクをRDMAでやりとりできる
15. 今回扱うSmartNIC Mellanox Bluefield-2 通信プリミティブ: • SoC関連の通信はすべてRDMAで完結する • クライアントからSoCに対するone-sided/two-sidedのRDMAリクエストを送る こともできる (1ホストに2つのサーバが載っているように見える) (②の経路) • SoC – ホスト間は相互にRDMAで通信できる (③の経路) • ただしRDMAを利用するためにNICコアを経由する必要があり，これが隠れたボトル ネックになる
16. 今回扱うSmartNIC Mellanox Bluefield-2 現状わかっていること: • SoCの計算能力は比較的弱い • オフロードされた処理の実行，ネットワーク要求の処理実行ともに • 通信パターン(①, ②, ③)による違いに着目した先行研究はほとんどない • READによりSoCのメモリにアクセスする場合はホストのメモリにアクセスするより 低レイテンシであることを示した先行研究はある • ③の経路でRDMAを使うと，RDMAをサポートするソフトウエアのオーバーヘッ ドによってDMAよりもレイテンシは大きくなる
17. 3. Characterizing SmartNIC Performance
18. テスト環境 サーバスペックは以下の表のとおり • SRV: サーバ (基本的に受信側) • RNIC: ConnectX-6 • SmartNIC: Bluefield-2 (SoC以外はRNICと同スペック) • CLI: クライアント(基本的に送信側) • RNIC: ConnectX-4 • Mellanox SB7890 (InfiniBand EDR (100Gbps) スイッチ) で相互接続 • (RoCEではなく) InfiniBandを利用
19. テスト環境 RDMAでの通信における最新のイケてる方法で評価 • one-sided primitivesの場合 • RCサービスタイプのQPを利用 • 応答サーバ側のメモリアドレスは10GB分の領域からランダムに選出 • two-sided primitivesの場合 • UDサービスタイプのQPを利用 • サーバ側は利用可能なすべてのCPUコアを利用するechoサーバにより クライアントからのメッセージに応答
20. テスト環境 • end-to-endのレイテンシ計測 • 1台のクライアントをキューイングによる影響を排除するために利用 • 最大11台のクライアントを用意してサーバのネットワークを飽和させ， ピークスループットを計測 上記以外に，RDMAのための最適化を実施 • メモリアドレスのアラインメント • 要求の非シグナル化 • ポーリングでのCQチェックによるCPU消費が無くなる • Huge pages
21. クライアント – ホスト間の通信
22. クライアント – ホスト間の通信 レイテンシ • SNICはRNICと比較してREAD, WRITE, SEND/RECVでそれぞれ15- 30%, 15-21%, 6-9%のレイテンシ増加 • PCIeスイッチやPCIe1の接続を通ることが原因 • 片方向のオーバーヘッドは150-200ns増加 • 小さなRDMAリクエスト(1-2μs)には十分大きな遅延
23. クライアント – ホスト間の通信 レイテンシ • READのほうが全体的にレイテンシが大きい • RNIC, SNICともに各PCIeリンクを(WRとWCの)2度通る必要があるため • WRITEではWCは省略される (図) • SEND/RECVではREAD/WRITEほど顕著な増加ではない • このレイテンシ増はサーバ側のCPUの負荷増によるものであるため，あまり重要 ではない
24. クライアント – ホスト間の通信 スループット • 小さなリクエストにおいてピークスループットが大幅に低下する • レイテンシの増大により，PCIeリクエストの完了を待つためにNICコアがパイプ ライン内で長時間停止することになる • 512Bより小さいペイロードにおいて， SmartNICはRNICと比較してREAD, WRITE, SEND/RECVでそれぞれ19-26%, 15-22%, 3-36%スループット低下 • それよりも大きなペイロードではネットワーク帯域がボトルネックになるため差 は無くなる
25. クライアント – ホスト間の通信 ボトルネック • NIC, PCIe1, PCIe0のうち最も小さい帯域幅がボトルネックになる • 今回ではNICが200Gbpsなのでここがボトルネック • 双方向通信のときは帯域幅の限界が2倍に近づく • 例: READパケットとWRITEパケットを同一リンク上で多重化
26. クライアント – ホスト間の通信 ボトルネック • 双方向通信のときは帯域幅の限界が2倍に近づく • 例: READパケットとWRITEパケットを同一リンク上で多重化可能 • 2つのクライアントからそれぞれR+W/W+Rのリクエストを投げた場合364Gbpsに • 両方から同じタイプ(R+R or W+W)のリクエストを投げた場合190Gbpsに
27. クライアント – ホスト間の通信 まとめ • SNICはペイロードが小さなリクエストの場合に損をする • スループットで最大36%，レイテンシで最大30%の性能低下 • SNICを利用する場合は他の通信経路の使用を検討すべき
28. クライアント – SoC間の通信
29. クライアント – SoC間の通信 レイテンシ • READ • PCIe0を通らないため，経路①と比較して14%低減 • PCIeスイッチを経由する関係上，RNICと比較するとまだ4-15%多い • WRITE • WCがNICコアから非同期に送られるため経路①と変わらず • SEND/RECV • SoCの計算能力がホストよりも低いため経路①よりも21-30%増大
30. クライアント – SoC間の通信 スループット • READ, WRITEでは2度PCIeリンクを経由する必要がなくなるため向上 • 512Bよりも小さいペイロードでは経路①と比較して1.08-1.48倍高速に • READに関してはRNICよりも高速になる • SoCのメモリとPCIeスイッチが近くに配置されているため？(詳細不明) • WRITEは相変わらずRNICより低いスループット • SoCのDRAMのチャネル数がホストよりも少ないため？ (SoCは1本，ホストは8本) • メモリへの読込は書込よりも高速なためREADの場合は問題になっていない • SoCはNICコアの一部しか利用できていないため？ • SEND/RECVは64%のスループット低下 • やはりSoCの計算性能の低さが原因
31. クライアント – SoC間の通信 ボトルネック • NIC, PCIe1のうち小さいほうの帯域幅がボトルネックになる • 今回もNICが200Gbpsなのでここがボトルネック • 双方向では2倍になるのもクライアント – ホスト間と同様
32. クライアント – SoC間の通信 Advice #1: 偏ったメモリアクセスを避ける • SoCコアはホストCPUと比べてサポートしている機能が少ない • one-sided primitivesにおいてメモリアクセスに良くない影響を及ぼす可能性が ある • ホストCPUでは広くサポートされている例: DDIO (Data Direct I/O) • LLC (last level cache) をNICコアが直接読み書きできるようにする機能 • SoCでもサポートされている例はあるがベンダ依存 (ARM CCI) • Bluefield-2は非対応
33. クライアント – SoC間の通信 Advice #1: 偏ったメモリアクセスを避ける • SmartNICがDDIOをサポートしないことによる問題点 • one-sided primitivesの性能は偏ったメモリアクセスにモロに影響を受ける • 偏った (skewed): 要求されたメモリアドレスが狭い範囲に収まるような場合 • LLCはDRAMにより高速でアクセスするので偏ったアクセスにも対応できる • DRAMの場合はすべてのメモリモジュールに同時にアクセスする必要がある
34. クライアント – SoC間の通信 Advice #2: ペイロードの大きなREADリクエストを避ける • 大きなペイロードのリクエストを利用することでネットワーク帯域幅 を全部利用することは一般的な最適化方法 • ペイロードサイズが9MBを超えるとパフォーマンスが落ちる • NICコアがhead-of-lineブロッキングの影響を受けるため
35. クライアント – SoC間の通信 Advice #2: ペイロードの大きなREAD要求を避ける head-of-lineブロッキング • 一般的には先頭パケットの処理落ち等により待機時間が発生する現象を指す • 今回のREADリクエストの場合 • NICコアがPCIeのreadトランザクションを発行してデータ取得 • データ自体はPCIeリンクのMTUに準じて複数のPCIeパケットに分割される • SoCコアのMTUはホストのMTUより小さい→より多くのPCIeパケットが必要 • ホストよりも多くのPCIeパケットの到着を待機→その間処理が停止する
36. クライアント – SoC間の通信 まとめ • one-sided primitivesは通常，ホストへ送るよりも高速 • 経由するPCIeリンクが少ないため (PCIe0を通らない) • two-sided primitivesはSoCが貧弱なので露骨に遅くなる • 特にone-sided primitivesを扱うときはホストに送るのか，SoCに送る のかを考えて実装することが必要 • DDIOがSoCでサポートされていないためメモリアクセスの偏りで性能低下 • リクエストのサイズが大きいとhead-of-lineブロッキングが発生し性能低下
37. SoC – ホスト間の通信
38. SoC – ホスト間の通信 レイテンシ • SoC→ホストは非常に高いレイテンシ (特にREAD) • SoCがリクエストを発行するのに時間がかかるため (グラフ左)
39. SoC – ホスト間の通信 レイテンシ • ホスト→SoCはSoC→ホストよりは低いが経路② (クライアント - SoC) よりは4-17%高い • クライアント→SoC: クライアント側PCIe→NW→PCIe1→PCIeスイッチ • ホスト→SoC: PCIe0→PCIeスイッチ→PCIe1→PCIe1→PCIeスイッチ 経路②よりも余分にPCIeの転送が発生する
40. SoC – ホスト間の通信 スループット • 512Bより小さなペイロードでは，どちらの方向でも要求側のプロセッ サがボトルネックになった • SoC→ホストで29Mreq/s，ホスト→SoCで51.2Mreq/s • 経路①，②の計測時は11台の要求側クライアントを使って応答側サーバを飽和さ せた • 今回は要求側がシングルにならざるを得ないので飽和させられない • READ, WRITE, SEND/RECVDEで似たような結果になった • ペイロードを大きくするとPCIeの帯域に制約を受けるようになる
41. SoC – ホスト間の通信 ボトルネック • R+R or W+Wの場合 • NICは関与しない，PCIeの帯域幅(256Gbps)に制約を受ける • 実際の帯域幅は204Gbps，NICの制約を受ける経路①/②は191Gbps • より多くのPCIeパケットが必要になっており256Gbpsに近づけていない可能性
42. SoC – ホスト間の通信 ボトルネック • R+W or W+Rの場合 • 単方向と変わりなし • 単方向でもPCIe1を2度通過するため実質双方向
43. SoC – ホスト間の通信 Advice #3: ペイロードの大きなREAD/WRITE要求を避ける • こちらもAdvice #2で触れたhead-of-lineブロッキングの影響を受ける • 先ほどと異なり，WRITEリクエストでも発生する • クライアント側(SoC→ホストの場合はSoC)から先にデータを読み取ってから サーバ側に書き込む必要がある • SoC→ホストのほうが先にPCIe1を通過する→MTUの問題がより顕著 • PCIe0 (ホスト→SoC) はMTU 512Bなので制約を受けにくい • 結果的にSoC→ホストのほうがより小さいペイロードで性能劣化する
44. SoC – ホスト間の通信 Advice #3: ペイロードの大きなREAD/WRITE要求を避ける • 200Gbpsでデータ転送する場合: • 293Mppsの処理能力がSmartNICに最低限必要 • SoC→PCIeスイッチ→PCIe1→NIC: 128B × 195Mpps • NIC→PCIe1→PCIeスイッチ， PCIeスイッチ→PCIe0→ホスト: 各512B × 49Mpps • クライアント→ホストの6倍，クライアント→SoCの1.5倍の処理能力を要求 ペイロードを小さくして要求パケット処理速度を下げることが必要
45. SoC – ホスト間の通信 Advice #4: doorbell batchingを利用する • 各リクエストをNICに向けて発行する時間はメモリマップI/O (MMIO) に大きく影響されている • 特にホストと通信するとき，MMIO起因のレイテンシが高くなる (左) • よく知られた最適化方法として，doorbell batchingがある • RNICが提供するバッチ処理
46. SoC – ホスト間の通信 Advice #4: doorbell batchingを利用する doorbell batching (DB) • PCIeの使用帯域幅を抑えるため，MMIOでのアクセスを減らす 1. 複数のリクエストを送信側のメモリ内でリンク 2. リンクしたリクエスト群をDMAで読み取るようにMMIOでNICに要求 結果的にN回分のMMIOアクセスを1回分に削減できる • 実質的に1つのQPに複数のWQEを詰め込める (通常は1つのQPに1つのWQE) • MMIOよりもCPUをバイパスしたDMAの方がPCIeの帯域幅消費が小さい
47. SoC – ホスト間の通信 Advice #4: doorbell batchingを利用する doorbell batching (DB) • クライアント – ホスト間のRNIC/SNICは2-30%のスループット向上 (グラフ右) • SoC – ホスト間でもSoC→ホストのとき顕著な改善がみられる • バッチサイズ16-80で2.7-4.6倍のスループット向上 • NICのDMAを利用することでSoCのメモリ読取が高速になったため
48. SoC – ホスト間の通信 Advice #4: doorbell batchingを利用する doorbell batching (DB) • ただしホストが送信側の場合はDBが役立つとは限らない • NIC DMAによるホストのメモリ読取はMMIOを利用するよりも低速 • 実際にバッチサイズが16，32，48のときそれぞれ9%，7%，6%スループットが低下 • 特にバッチサイズが小さいと性能低下が大きい，64以上では逆転する
49. SoC – ホスト間の通信 まとめ • doorbell batchingはSoC→ホストなら有効 • ただしホスト→SoCはバッチサイズが小さいと逆効果 • 他の経路と異なりPCIe1の単方向の帯域幅 (256Gbps) がボトルネック • これを理解していないと十分なNIC帯域幅を活かせない可能性がある • SoC – ホスト間で大きなペイロードのリクエストは避けるべき
50. 4. Concurrent communication paths
51. マシン間通信 + マシン間通信 クライアント – ホスト間 + クライアント – SoC間でテスト
52. スループット • READ, WRITE, SEND/RECVはそれぞれ，元の低い方の経路の1.45倍, 1.50倍, 3.3倍向上 • 本来，片方のパスでNICコアを占有するので競合するはず… • おそらくパス毎に予約されているNICコアがある • 両方のパスを使用するとそれらも有効になるので動作するNICコアが多くなり ピーク性能が向上する？ • ドキュメントには記載なし→ベンチマークプログラムを作成して確認 マシン間通信 + マシン間通信
53. スループット 作成したベンチマーク • 0Bのペイロードをもつリクエストを発行 • DMAの発行を回避するため • これによりPCIe1に到達する前，つまりNICコアに到達した時点で応答が返される →純粋に各リクエストの処理に充てられたNICコアの数を推定できる • 各応答サーバ (ホスト/SoC)へのリクエスト送信を増やして応答を飽和させる • 先にホスト側を飽和させた状態でSoCを飽和させた場合 (SNIC①+②)，またその逆を それぞれテスト マシン間通信 + マシン間通信
54. スループット ベンチマーク結果 • どちらから先に飽和させても同様のパフォーマンス • SNIC① (クライアント – ホスト) 単独よりも4-13%高いスループット • SNIC② (クライアント – SoC) 単独よりも5-10%高いスループット • WRITEの場合はどちらもどちらのパターンも同じ結果で並列で使用した方が高速 • SNIC①+②/SNIC②+①のスループットは195Mpps • SNIC①とSNIC②の単純な合計スループットは352Mpps →ほとんどのNICコアは共有されていることがわかる →複数の経路を同時使用することは困難 マシン間通信 + マシン間通信
55. マシン間通信 + マシン内通信
56. クライアント→ホスト間 + ホスト→SoCの結果から分析 • 実験方法 1. 5台のクライアント→ホストで経路①を飽和 2. ホストで24スレッドのクライアントを動作，SoCにリクエスト送信 • マシン間通信のパフォーマンスが低下 • ペイロードが大きくなるとネットワーク帯域幅がボトルネックに • ホスト – SoC間の通信はSNIC上の他の通信経路にも影響を及ぼす • NICコア (実質的にはPCIe1とPCIeスイッチ) がホストとSoCにブリッジ • RDMAリクエスト毎により多くのPCIeパケットを狭いPCIe帯域幅で処理するこ とになり，他の経路を圧迫する • マシン内/間通信は他の組み合わせでも同様の動作がみられる マシン間通信 + マシン内通信
57. ボトルネック • マシン間通信の双方向通信では400Gbps近くの帯域幅が出る • PCIe1では片方向200Gbps分しか利用していない →56Gbps分をマシン内通信に割り当てれば効率的なのでは？ • PCIe1では折り返しの通信が発生するので片方向・双方向で利用できる帯域幅は どちらも56Gbps • データ処理の一部をSoCでオフローディングすることが最適なのかもしれない 複数経路の同時使用
58. まとめ • マシン間通信をクライアント – ホスト/SoC間で同時に使用するとNIC コアをフル活用できる • 特に双方向のアクセス (R+W/W+R) で有効 • マシン内通信を併用する場合は他の経路に干渉しないよう配慮が必要 • 本来の目的であるマシン間通信を阻害しないように • 今回の場合はNICがボトルネックになる→余剰のPCIe帯域幅を活用できる可能性 複数経路の同時使用
59. 5. Discussion
60. Bluefield-2以外のSmartNICについて • 他のSmartNICも基本的には同じようなハードウエア構成 • 例: • Broadcom NetXtreme 100Gbps RNIC • NVIDIA Bluefield-3 (Bluefield-2の後継) → 今回の研究手法・分析ツール・パフォーマンスモデルは他の SmartNICにも適用できるはず
61. 今後開発されるSmartNICに対する提案 • CXL (Compute Express Link) のサポート • PCIeベースの規格 • ホスト-SoC間のPCIeの帯域使用効率が大幅に向上 • プログラミングは難しくなる • SoC OSとホストOSの強力な連携が必要 • CCI (Cache Coherent Interface) のサポート • クライアント – SoC間の通信におけるメモリアクセスの偏りの問題を 軽減できる
62. 6. Conclusion
63. Conclusion • SmartNICを活用して高性能な分散システムを構築するために は，低レベルなハードウエアについての十分な理解が必要 • 計算の不均一性はSmartNICによるネットワークの性能に対し て大きな影響を及ぼす • 本論文で示された測定結果を元にしたアドバイスを参考にする ことで，開発者はSmartNICに起因するネットワークの異常発 生を回避することができる