> [!abstract] 概要(NSDI '23 abstract の日本語訳) > 近年、クラウドにおける RDMA の採用が広がっており、第一者ワークロードの高速化と CPU サイクルの解放によるコスト削減を実現している。現在、クラウドプロバイダは第三者ワークロードの利益のために、汎用ゲスト VM で RDMA をサポートしようとしている。このためには、あるテナントの RDMA ワークロードが別のテナントの RDMA 性能に悪影響を与えないよう、強力な性能分離を提供しなければならない。パブリッククラウドにおけるネットワーク性能分離には多くの取り組みがあるが、RDMA はその複雑な NIC マイクロアーキテクチャリソース(例: NIC キャッシュ)に起因する独自の課題をもたらすことがわかった。 > > 本論文では、RNIC のマイクロアーキテクチャリソースが性能分離に与える影響を体系的に理解することを目指す。RDMA 操作が RNIC リソースをどのように使用するかを表現するモデルを提示する。このモデルを用いて、RDMA 性能分離ソリューションを評価するテストスイートを開発する。我々のテストスイートは、様々なシナリオで既存のすべてのソリューションを破ることができる。我々の結果は、最大手の RDMA NIC ベンダーの一つによって確認・再現された。最後に、テスト結果に基づき、将来の RDMA 性能分離ソリューション設計に関する新たな知見をまとめる。 ## 論文情報 - タイトル: Understanding RDMA Microarchitecture Resources for Performance Isolation - 著者: Xinhao Kong, Jingrong Chen([[Duke University]]); Wei Bai([[Microsoft]]); Yechen Xu([[Shanghai Jiao Tong University]]); Mahmoud Elhaddad, Shachar Raindel, Jitendra Padhye([[Microsoft]]); Alvin R. Lebeck, Danyang Zhuo([[Duke University]]) - 媒体: 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI '23)、2023-04-17〜19、Boston, MA - テストスイート(Husky)公開先: https://github.com/host-bench/husky (本文言及、URL は未検証のため直接アクセスしていない) ## 概要 クラウドプロバイダがゲスト VM に RDMA を提供する際、RNIC(RDMA NIC)内部のキャッシュ・処理ユニット・PCIe 帯域といった「マイクロアーキテクチャリソース」を経由した性能分離違反が起こりうることを実験的に示した論文である。RDMA verb(標準 RDMA プログラミング API)の挙動をモデル化し、そのモデルに基づいて既存の性能分離ソリューション(SR-IOV・HW TC・Justitia)を破壊するテストスイート Husky を構築した。全ての既存ソリューションが Husky のテストに合格しなかったことを示し、allreduce や eRPC-based Masstree のような実アプリケーションでも影響が波及することを実証した。 ## 問題設定 - **入力**: 商用 RNIC(NVIDIA ConnectX-5/ConnectX-6 Dx、Chelsio T62100-LP-CR、Intel E810)上で稼働する、複数テナントの RDMA verb 操作列。 - **出力**: 攻撃者(attacker)テナントと被害者(victim)テナントの組み合わせにおける、既存の性能分離ソリューションの分離違反の有無。 - **前提条件**: クラウドプロバイダはテナントのアプリケーションを制御できず、テナントは任意の(悪意ある場合も含む)RDMA verb を発行しうる。RNIC はブラックボックスであり、ベンダー固有のハードウェアカウンタ(NVIDIA の NEO-Host)を除き内部状態は観測できない。 論文冒頭では、SR-IOV とハードウェアトラフィッククラス分離(HW TC)を組み合わせた最先端の分離機構が既に破られることを、動機付けの実験として示している。 **Figure 1: 既存手法における性能分離違反** ![[_attachments/nsdi23-kong/fig01-isolation-violation.png]] (Figure 1. victim 単独では約 80 Gbps を達成し(Victim alone)、isolation を有効化すると victim・attacker はそれぞれ 50 Gbps の保証帯域に収束する(Isolation enabled、緑破線)。しかし attacker がわずか 1 Gbps の攻撃トラフィックで特定の RNIC マイクロアーキテクチャリソースを枯渇させ始めると(Attacker starts)、victim の帯域は直ちに約 2 Gbps まで低下し、50 Gbps の保証を violate する。Source: Figure 1.) ## 提案手法 - **アーキテクチャ**: RDMA verb を control verb(オブジェクト割り当て・破棄、例 `ibv_reg_mr`)と data verb(データ転送、例 `ibv_post_send`)に分類し、それぞれが RNIC 内の 4 種類のマイクロアーキテクチャリソース——NIC 帯域・PCIe 帯域・処理ユニット(PU)・NIC キャッシュ(ICM/MTT/MPT/WQE キャッシュ)——をどう消費するかを実験的に特定する(Figure 3)。 **Figure 3: RDMA NIC のマイクロアーキテクチャハードウェア詳細** ![[_attachments/nsdi23-kong/fig03-rnic-microarchitecture.png]] (Figure 3. ドアベルが鳴らされると、RNIC はまずホスト DRAM から control/data verb リクエストを取得する。(1) リクエストの取得・処理に必要なメタデータ(例: QP コンテキスト)は複数種類のキャッシュに格納されており、RNIC はキャッシュから直接メタデータを取得できるか、(2) キャッシュミス時は DRAM から取得する(図中の赤線)。その後 RNIC はリクエストを処理し、(3) control verb の場合は応答をホスト DRAM に送り返し、data verb の場合はペイロード読み出しの DMA リクエストを発行する。(4) ホスト DRAM からのデータ読み出し後、RNIC は (5) データをネットワークパケットに処理し (6) ファブリックへ送出する。対称的な受信側は簡単のため図示していない。Source: Figure 3.) - **アルゴリズム/手法の詳細**: 図 2 に示す RDMA ワークフロー(ユーザアプリケーション → ユーザ空間ライブラリ → カーネルドライバ → RNIC)の各段階で、control verb はカーネルドライバ経由でコマンドキューに投入されドアベルが鳴らされる一方、data verb はカーネルバイパスで直接 RNIC に発行される。この経路の違いが後述の Key finding #3(control verb はカーネルによってスロットルされる)の根拠になる。 **Figure 2: RDMA ワークフローの概要** ![[_attachments/nsdi23-kong/fig02-rdma-workflow.png]] (Figure 2. verb 処理ロジックの多くが RNIC にオフロードされている様子を示す。control verb(黒矢印)は `ibv_open_device`・`ibv_alloc_pd`・`ibv_reg_mr`・`ibv_create_cq`・`ibv_create_qp`・`ibv_modify_qp` を含み、ユーザ空間ライブラリとカーネルドライバの双方を経由して RNIC の Control Verbs Process に到達する。data verb(赤矢印)は `ibv_post_send`・`ibv_post_recv`・`ibv_poll_cq` を含み、ユーザ空間ライブラリから直接 RNIC の Data Verbs Process へカーネルバイパスで到達し、ファブリックへ送出される。Source: Figure 2.) - **実装上の工夫**: 4 種類のマイクロアーキテクチャリソースそれぞれについて、それを枯渇させる合成ワークロードを設計し、既存の RDMA トラフィック生成ツール Collie([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])のトラフィックエンジンを拡張して、control verb ワークロードやエラー処理ワークロードを含む柔軟な合成トラフィックを生成できるようにした。Husky は合計 52 種類の attacker 合成ワークロード(NIC BW 用 6、PCIe BW 用 4、NIC PU 用 14、NIC キャッシュ用 28)と 20 種類の victim 合成ワークロードを含む。分離違反の定義は、victim の実測性能が保証性能の `(1-α)min(Ba, Bg)` 未満になった場合とし(α=25%、Ba は単独実行時の性能、Bg は保証帯域)、既存ソリューションの多くがこの帯域保証型の定義に還元できることを確認した上で使用している。 **Figure 7: verb とマイクロアーキテクチャリソースの関係(リソース消費モデル)** ![[_attachments/nsdi23-kong/fig07-resource-consumption-model.png]] (Figure 7. 矢印は重いリソース消費を示す。data verb(SEND/WRITE/READ/FAA/CAS)の post request と wide range access は PCIe 帯域・NIC 帯域・NIC キャッシュ・処理ユニットに関わり、control verb(QP/CQ/MR/PD/Context の allocation・deallocation・modification)は主に NIC キャッシュを、RNIC のエラー処理(transport timeout・receiver not ready)は主に処理ユニットを消費する。Source: Figure 7.) ## 新規性 既存研究(HERD・FaSST・eRPC・ScaleRPC・Flock・Kalia+ の RDMA 設計ガイドライン)は、アプリケーション開発者の視点から RNIC マイクロアーキテクチャリソースの制約を回避する方法を論じてきた。先行研究 Collie([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]、同著者陣による NSDI '22 論文)は第一者トラフィックの通常操作に基づく探索空間からRDMA 性能異常を体系的に発見したが、control verb・エラー処理・高コストな atomic verb は探索空間に含まれていなかった。本論文は、クラウドプロバイダがテナントのアプリケーションを制御できないという前提に立ち、control verb と error handling を含むすべての RDMA 挙動をマイクロアーキテクチャリソースの観点から横断的に検証した点で新規性を持つ。また PicNIC・FairNIC のような他 NIC 性能分離研究と比較して、RDMA 固有のリソース(RNIC キャッシュ等)に焦点を当てる。 ## 実験設定 - **実験環境**: NVIDIA ConnectX-5 EN・ConnectX-6 Dx(RoCE)、Chelsio T62100-LP-CR(iWARP)、Intel E810(RoCE)の 100 Gbps RNIC 4 種。サーバは Intel Xeon Gold 5215、Ubuntu 20.04、カーネル 5.11、NVIDIA 側は 5.4-OFED ドライバ、ファームウェア 16.31.1014。2 台のサーバを 100 Gbps スイッチで接続。実アプリケーション評価では 4 台の物理サーバを使用。 - **データセット/ワークロード**: Husky が生成する 52 種の attacker 合成ワークロードと 20 種の victim 合成ワークロード。実アプリケーションとして OSU benchmark の allreduce(RDMA ベース MPI 実装上)と eRPC ベース Masstree キーバリューストア。 - **比較対象**: (1) NVIDIA SR-IOV(2 VF、VF ベースレートリミッタで各 50 Gbps 制限)、(2) NVIDIA HW TC(トラフィッククラス分離)、(3) SR-IOV + HW TC、(4) Justitia(ソフトウェアベースのユーザ空間レートリミッタ/ペーサー)、(5) Justitia + HW TC。Chelsio・Intel のハードウェア分離機構は有効化を試みたが実現できなかった。 - **評価指標**: 帯域(Gbps)、リクエストレート(Mrps/rps)、レイテンシ(µs)。分離違反は victim の実測性能が `(1-α)min(Ba, Bg)`(α=25%)を下回るかどうかで判定。 ## 実験結果 - **定量評価**: control verb による攻撃(MR deregistration、1 スレッドで約 5K registration/s)は、victim の帯域を 96.6 Gbps から 48.0 Gbps へ低下させ、MTT キャッシュミス率を 17.2% から 49.1% へ増加させた(Table 1)。 Table 1: MR control verb が MTT キャッシュを枯渇させ帯域を低下させる | Scenarios | Alone | Registration | Deregistration | |---|---|---|---| | BW / Gbps | 96.6 | 95.9 | 48.0 | | Miss Rate | 17.2% | 22.9% | 49.1% | (Table 1. victim は単独では 96.6 Gbps、attacker が MR の登録(registration)を継続する場合は 95.9 Gbps とほぼ影響を受けないが、MR の登録解除(deregistration)を継続すると帯域は 48.0 Gbps まで低下し、MTT キャッシュミス率が 49.1% に達する。Source: Table 1.) data verb 間の PU 競合は verb の複雑さに依存し、NVIDIA ConnectX-5 では READ 単独で 60 Mrps を達成する victim が、attacker が CAS(compare-and-swap)を実行すると 3 Mrps まで低下する(Figure 4)。 **Figure 4: 異なる data verb 間の PU 競合(NVIDIA)** ![[_attachments/nsdi23-kong/fig04-pu-contention-nvidia.png]] (Figure 4. 各サブ図の左端バーは victim を単独実行した場合のリクエストレート、右 5 本は attacker(w/SEND・w/WRITE・w/READ・w/FAA・w/CAS)と同時実行した場合の victim のレート。SEND・WRITE は単独で 90 Mrps 超だが、READ は約 60 Mrps、FAA・CAS はそれぞれ 5.2 Mrps・4.8 Mrps に留まる。Source: Figure 4.) Chelsio T62100-LP-CR(iWARP)でも同様の競合パターンが確認され、WRITE 単独で 4.76 Mrps の victim が SEND attacker により 55.0%、READ attacker により 73.1% 低下する(Figure 5)。 **Figure 5: 異なる data verb 間の PU 競合(Chelsio)** ![[_attachments/nsdi23-kong/fig05-pu-contention-chelsio.png]] (Figure 5. 各サブ図の左端バーは victim 単独実行時のレート、右 3 本は attacker(w/SEND・w/WRITE・w/READ)同時実行時の victim のレート。Chelsio の iWARP は ATOMIC 操作をサポートしないため 3 種類の data verb のみで評価している。Source: Figure 5.) RNR(Receive Not Ready)エラーは NVIDIA ConnectX-5/6 の RNIC 処理ユニットを完全に停止させ、victim の帯域を 93.53 Gbps から 0.018 Gbps へと事実上ゼロにする(Table 2)。 Table 2: RNR エラーが帯域に与える影響(単位: Gbps) | Scenario | Victim Bandwidth | SEND Bandwidth | |---|---|---| | Victim Only | 97.07 | - | | w/o RNR | 93.53 | 4.01 | | w/ RNR | 0.018 | 0 | (Table 2. attacker が正常に SEND を送出する場合(w/o RNR)は victim の帯域を 4 Gbps 消費するに留まるが、受信側が受信リクエストを投入せず RNR エラーを誘発すると(w/ RNR)、attacker 自身の帯域もゼロになると同時に victim の帯域も 0.018 Gbps まで崩壊する。Source: Table 2.) PCIe 帯域はリクエストサイズが特定範囲(29〜256 バイト付近)にあるときにのみボトルネックになることを、理論モデルと実測の両方で示した(Figure 6)。 **Figure 6: アプリケーションが消費する PCIe 帯域と RNIC 帯域** ![[_attachments/nsdi23-kong/fig06-pcie-bandwidth.png]] (Figure 6. 横軸はメッセージサイズ(バイト)、縦軸は帯域(Gbps)。ペイロードが 28 バイト未満では WQE と同一 MMIO に埋め込まれるため PCIe 消費は増加しないが、29〜256 バイト付近では PCIe TX 帯域(PCIe Bw)が NIC 帯域(NIC Bw)を上回り、追加の DMA が必要になる範囲が生じる。Source: Figure 6.) 以上の Key finding #1〜#4 を統合した既存ソリューションの比較を Table 3 に示す。SR-IOV・HW TC・SR-IOV+HW TC・Justitia・Justitia+HW TC のいずれも、RC の Error Handling を除いて全項目で分離に失敗した(✗)。 **Table 3: マイクロアーキテクチャリソース枯渇による性能分離違反の一覧** ![[_attachments/nsdi23-kong/table03-isolation-solution-comparison.png]] (Table 3. ✓ は性能分離が適切に機能したことを、✗ は Husky が attacker/victim の組み合わせで分離を破壊できたことを示す。Justitia は同一デバイスを使うアプリケーション間でしか分離できないため SR-IOV とは組み合わせていない。RC の Error Handling のみ SR-IOV・SR-IOV+HW TC で分離に成功しているが、UD & UC の Error Handling・Data Verbs・NIC キャッシュ・PCIe 帯域はすべてのソリューションで分離に失敗している。Source: Table 3.) 実アプリケーション評価では、allreduce ワークロードの実行レートが cache attack で SR-IOV+HW TC 使用時に約半分、Justitia+HW TC 使用時に 71.3% 低下し、PU attack ではほぼ完全に停止した(Figure 8)。eRPC-based Masstree では GET レートが同様に低下し(Figure 9)、レイテンシは PU attack 下で無限大(タイムアウト)に達した(Figure 10)。 **Figure 8: リソース枯渇下での allreduce の結果** ![[_attachments/nsdi23-kong/fig08-allreduce-results.png]] (Figure 8. No protection(オレンジ)は保護機構なしの実行レート、以降は Justitia+HW TC(水色)と SR-IOV+HW TC(青)を有効化した場合の No attack・BW attack・PCIe attack・Cache attack・PU attack 下でのレート。水平の赤線は各分離機構の違反しきい値を示し、Cache attack と PU attack はいずれのしきい値も下回る。Source: Figure 8.) **Figure 9: リソース枯渇下での Masstree の GET レート** ![[_attachments/nsdi23-kong/fig09-masstree-get-rate.png]] (Figure 9. Colocated(attacker VM が client と同一ホスト)と Non-colocated(別ホスト)の双方について、No Protection・No attack・BW attack・PCIe attack・Cache attack・PU attack 下の GET レートを示す。PU attack ではレートがほぼゼロになる。Source: Figure 9.) **Figure 10: リソース枯渇下での Masstree のレイテンシ** ![[_attachments/nsdi23-kong/fig10-masstree-latency.png]] (Figure 10. p50/p99 レイテンシを Colocated/Non-colocated 別に示す。PU attack 下ではレイテンシが測定上限(100 µs 超、"+∞" と表記)に達する。Source: Figure 10.) - **アブレーション**: 明示的なアブレーション研究は行われていないが、攻撃タイプ(BW/PCIe/Cache/PU)ごとの効果比較が事実上アブレーションの役割を果たしている。PU attack が最も強力で、Cache attack がそれに次ぐという傾向が allreduce・Masstree の両方で一貫して観測された。 - **定性評価**: NVIDIA は本論文の全発見を自社環境で再現・確認し、Key finding #1(control verb のキャッシュミス)については NIC 内部 QoS スケジューリングポリシーの調整、Key finding #4(PCIe 帯域)については既に把握済みの現象であるとの詳細な技術的解説を提供した(Appendix B)。 ## 考察 論文は、architectural resource(帯域など)を分離する既存機構(SR-IOV・HW TC)は、マイクロアーキテクチャリソース(キャッシュ・PU)を分離対象に含まないため原理的に不十分であると論じる。ソフトウェアベースの Justitia も、RNIC 内部で処理されるエラーハンドリングを制御できず、キャッシュ・PCIe を考慮しないため同様に不十分である。著者らは、将来の性能分離ソリューションにはハードウェアサポート(Intel RDT のようなキャッシュ管理機構の RNIC 版)と、ユーザ空間ライブラリではなく独立した保護ドメインに置かれる「間接化レイヤー」の両方が必要だと結論づける。 ## 強み / 弱点・課題 - **強み**: 4 種類のリソース(NIC 帯域・PCIe 帯域・PU・キャッシュ)を横断する体系的なリソース消費モデルを構築し、それに基づくテストスイート Husky で既存の全ソリューションを実際に破壊して見せた点。産業界の主要 RNIC ベンダー(NVIDIA)による発見の確認・再現を得ており、実務的インパクトが検証されている。 - **弱点・課題**: 著者ら自身が認める限界として、RNIC がブラックボックスであるため定量的なリソース使用量(キャッシュサイズ等)は不明であり、モデルは定性的なものに留まる。Chelsio・Intel の RNIC ではハードウェアベース分離機構を有効化できず、評価対象から除外されている。また Justitia の評価では Husky のトラフィックを Justitia の改変済みドライバ経由に制限しており(セキュリティ回避を意図的に除外)、パブリッククラウド運用での悪意あるテナントを完全には模擬していない。