仮想化基盤や NFV 系のシステムを更新するとき、SR-IOV を引き続き必須要件にするべきか、通常の virtio や vhost-user などのソフトウェアデータパスへ戻せるのかが論点になることがあります。特に CPU 世代が大きく変わる場合、「新しい CPU なら SR-IOV なしでも十分ではないか」という判断は一見自然に見えます。
CPU 性能の向上によって、従来は SR-IOV が必要だった処理を、ソフトウェアデータパスでも実現できる可能性はあります。したがって、SR-IOV を外すこと自体が常に誤りというわけではありません。しかし、CPU が新しくなるという理由だけで SR-IOV 要件を外す判断は短絡的です。
まず確認すべきなのは CPU の型番ではありません。現行構成がなぜ SR-IOV を前提として設計されたのか、という元の設計理由です。既存環境の更新では、現在の技術要素を一度白紙に戻して考えるだけでは不十分です。現行設計に含まれている前提、制約、検証結果を確認し、その前提が新しい環境でも有効なのかを再評価する必要があります。
書籍
作って理解する仮想化技術 – ハイパーバイザを実装しながら仕組みを学ぶ
KVM、QEMU、仮想デバイス、I/O 仮想化、ハイパーバイザーの仕組みを低レイヤから理解したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
SR-IOV が必要だった理由は一つではない
現行システムで SR-IOV が採用された理由は、大きく二つに分けて考えられます。一つ目は、純粋なスループットやパケット処理性能の不足です。当時の CPU やソフトウェアデータパスでは、virtio、vhost、仮想スイッチなどを通した構成で必要な Gbps や pps を実現できなかったため、SR-IOV によってホスト側の仮想ネットワーク経路を短縮した可能性があります。
この場合、CPU 世代、NIC 性能、virtio、vhost、Open vSwitch などが進歩したことで、次期システムではソフトウェアデータパスでも要求性能を満たせる可能性があります。したがって、SR-IOV を外せるかどうかを再検証する余地はあります。ただし、これはあくまで可能性です。「CPU が新しいので性能が出るはず」ではなく、現行と同等の条件で実測し、要求を満たせることを確認して初めて、SR-IOV を外す判断が成立します。
二つ目は、最大スループット以外の理由です。レイテンシーを一定範囲に収める、ジッターを抑制する、他の VM やワークロードから受ける影響を小さくする、NIC キューや帯域を分離する、高負荷時にも性能を予測可能にする、ホスト側の CPU 使用量を抑える、といった要件が採用理由だった可能性があります。
これらが採用理由だった場合、CPU 性能が向上したことだけでは SR-IOV を外す根拠になりません。CPU が高速になれば、平均的な処理時間や最大スループットが改善する可能性はあります。しかし、ホスト側の仮想スイッチ、vhost、virtio、CPU スケジューラー、他ワークロードとの資源競合が存在するというデータパスの性質は残ります。性能分離や予測可能性は、CPU の絶対性能だけでは保証できません。
CPU 性能の向上とデータパスの変更は別の話である
KVM 上の VM で一般的な仮想 NIC を使用する場合、代表的な受信経路には、物理 NIC、ホスト側 NIC ドライバー、Linux bridge または Open vSwitch、tap または vhost-net、virtio-net、ゲスト OS のネットワークスタック、アプリケーションが含まれます。実際の経路は、Linux bridge、Open vSwitch、vhost-net、vhost-user などの構成によって異なります。
| 構成 | パケットが通る主な要素 | 設計上の意味 |
|---|---|---|
| virtio + Linux bridge / OVS | ホスト NIC、仮想スイッチ、tap / vhost、virtio、ゲスト OS | 汎用性が高いが、ホスト側データパスを通る |
| OVS-DPDK + vhost-user | OVS-DPDK、vhost-user、virtio、ゲスト OS | ホスト側 vSwitch を userspace datapath に寄せる |
| SR-IOV VF | NIC 内部の VF、PCI passthrough / IOMMU、ゲスト VF ドライバー | ホスト側の仮想スイッチ経路を通常のデータ通信から外す |
CPU が高速化すれば、NIC 割り込み、softirq、仮想スイッチでの転送、virtqueue の操作、メモリー管理、CPU スケジューリングなどをより短時間で実行できます。そのため、同じデータパスでもスループットや pps が向上する可能性はあります。しかし、CPU が高速になっても、パケットが通過する仮想スイッチ、vhost、virtio などの処理経路が消えるわけではありません。
CPU 性能の向上は、既存の経路を速く通過できるようにします。SR-IOV は、その経路自体を変更します。この二つは代替関係に見えることがありますが、本質的には異なる設計変数です。
SR-IOV は仮想 NIC のデータパスを変える
SR-IOV では、物理 NIC の Physical Function から Virtual Function を生成し、その VF を VM や Pod へ PCI デバイスとして割り当てます。VM へ VF を直接割り当てる場合、通常のデータ通信では、ホスト側の Linux bridge、ソフトウェア vSwitch、tap、vhost-net、virtio-net を経由しません。
Intel の SR-IOV for NFV Solutions に関する資料でも、VF を VNF の VM またはコンテナへ割り当てる構成は、ハイパーバイザー上の vSwitch をバイパスし、低いオーバーヘッドで高い性能を得る方式として説明されています。Linux カーネルの VFIO 文書では、IOMMU によって保護された直接デバイスアクセスを VM やユーザー空間へ提供する仕組みが説明されています。
SR-IOV は、CPU を高速化する技術ではありません。仮想 NIC をソフトウェアで中継する方式から、NIC の PCI 機能を直接割り当てる方式へデータパスを変更する技術です。そのため、SR-IOV を外すということは、単に高速化機能を一つ減らす変更ではありません。ホスト側の仮想ネットワークを経由しない設計から、再びソフトウェアデータパスを経由する設計へ変更することを意味します。
DPDK はパケット処理モデルを変える
DPDK では、Poll Mode Driver が NIC の RX / TX ディスクリプターをユーザー空間から直接扱います。一般的な Linux ネットワークでは、NIC がパケットを受信すると、カーネルのネットワークスタックを経由してソケットへ到達します。DPDK では、専用の論理コアが NIC キューをポーリングし、複数のパケットを burst 単位で取得して処理します。
DPDK では、パケットを rte_mbuf で表現し、mempool から割り当てて再利用します。NIC は、あらかじめ用意されたメモリー領域へ DMA で受信データを書き込みます。そのため、通常のカーネルネットワークスタックを通過した後に、カーネル空間からユーザー空間へパケットをコピーする経路を回避できます。
ただし、DPDK を単純に「ゼロコピー技術」と表現するのは正確ではありません。NIC から DPDK アプリケーションが扱う mbuf までの経路では、通常のカーネル・ユーザー間コピーを回避できます。しかし、アプリケーション内でのパケット再構築、暗号化、複製、別プロセスへの受け渡し、vhost-user 経由の VM 転送などでは、追加コピーが発生する場合があります。DPDK は、システム内のすべてのコピーを自動的に排除する技術ではなく、NIC キュー、ディスクリプター、DMA バッファー、CPU コアを、ユーザー空間のパケット処理に適した形で使用するためのデータプレーン基盤です。
SR-IOV と DPDK は排他的な選択肢ではない
SR-IOV と DPDK は、どちらか一方を選ぶ技術として扱われることがあります。しかし、両者が変更する範囲は異なります。SR-IOV は、主として物理 NIC から VM や Pod までの I/O 経路を変えます。DPDK は、PF や VF を受け取った OS またはアプリケーション内でのパケット処理方式を変えます。
| 構成 | 主なデータパス | 主な判断軸 |
|---|---|---|
| virtio + カーネルネットワーク | ホストとゲストの汎用ネットワークスタックを使用 | 運用性、互換性、可搬性 |
| SR-IOV + ゲストカーネルドライバー | VF を直接割り当て、ホスト側の仮想 NIC 経路を短縮 | ホスト側オーバーヘッド、性能分離、デバイス管理 |
| SR-IOV + ゲスト DPDK | VF を直接割り当て、ゲスト内でもカーネルスタックをバイパス | pps、レイテンシー、専用コア、NUMA |
| OVS-DPDK + vhost-user | ホスト側 vSwitch と VM 間を userspace datapath で処理 | 仮想スイッチ機能と高速化の両立 |
| ベアメタル DPDK | PF または VF を DPDK アプリケーションが直接使用 | 専用データプレーン、最大性能、運用制約 |
Open vSwitch の公式文書では、DPDK vhost-user ポートがゲストの virtio-net デバイスと接続され、OVS プロセスからゲストの virtqueue とパケットバッファーへアクセスする構造が説明されています。議論すべきなのは「SR-IOV か DPDK か」ではありません。物理 NIC からアプリケーションまでのどの区間にオーバーヘッドがあり、どの区間を短縮、専用化、分離する必要があるのかを考える必要があります。
帯域が同じでもパケット処理量は同じではない
CPU 性能で十分かどうかを判断するとき、Gbps だけを見るのは危険です。同じ帯域でも、パケットサイズによって 1 秒間に処理しなければならないパケット数は大きく変わります。Ethernet のプリアンブルと Inter-Packet Gap を含めた理論値では、10GbE の 64 バイトフレームは約 14.88Mpps、100GbE の 64 バイトフレームは約 148.81Mpps になります。
| 回線速度 | 64 バイトフレーム | 1518 バイトフレーム |
|---|---|---|
| 10GbE | 約 14.88Mpps | 約 0.81Mpps |
| 100GbE | 約 148.81Mpps | 約 8.13Mpps |
同じ 100Gbps でも、64 バイトフレームでは 1518 バイトフレームの約 18 倍のパケットを処理しなければなりません。大きなパケットを使用した試験で 100Gbps を達成できても、小さなパケットで同じ帯域を維持できるとは限りません。ルーター、ファイアウォール、NAT、ロードバランサー、VPN ゲートウェイなどでは、Gbps だけでなく pps や Mpps を確認する必要があります。
cycles per packet は効率を確認する指標になる
「1 コアで何 Mpps を処理できるか」という数値は分かりやすい一方、それだけでは CPU 効率を十分に説明できません。パケット処理では、1 パケットを処理するために何 CPU サイクルを消費したかという観点も重要です。
NVIDIA の DPDK 24.11 性能レポートにある Test #2 では、Xeon Platinum 8380 と ConnectX-6 Dx を使用した testpmd のシングルコア試験で、64 バイトフレーム 79.01Mpps、CPU cycles per packet 24 という結果が報告されています。1518 バイトフレームでは 16.25Mpps、197.393Gbps、CPU cycles per packet 23 です。
| フレームサイズ | フレームレート | スループット | CPU cycles per packet |
|---|---|---|---|
| 64 バイト | 79.01Mpps | 40.453Gbps | 24 |
| 128 バイト | 77.93Mpps | 79.800Gbps | 23 |
| 256 バイト | 74.40Mpps | 152.371Gbps | 24 |
| 512 バイト | 46.99Mpps | 192.474Gbps | 22 |
| 1518 バイト | 16.25Mpps | 197.393Gbps | 23 |
この値は、一般的なネットワークアプリケーションでも同じ性能が出ることを意味しません。testpmd による単純な転送試験であり、ACL、NAT、暗号化、セッション管理、経路検索などの処理は含まれていません。それでも、cycles per packet には意味があります。最終的な Mpps だけでなく、パケット当たりの処理コストを見ることで、CPU 性能によって押し切ったのか、データパスやソフトウェア実装が効率化されたのかを区別できるからです。
OVS-DPDK でも CPU 更新とデータパス最適化は別々に効く
Intel の Open vSwitch – Optimized Deployment Benchmark では、OVS-DPDK、VXLAN、32 個の VIRTIO user port、100 万フローを使用した構成が評価されています。この試験では、CPU を第 2 世代 Xeon Scalable から第 3 世代 Xeon Scalable へ変更した結果、パケットサイズに応じて 14 から 17％のスループット向上が報告されています。
| パケットサイズ | 第 2 世代 Xeon | 第 3 世代 Xeon | 向上率 |
|---|---|---|---|
| 112 バイト | 5,874.95Mbps | 6,704.08Mbps | 14％ |
| 256 バイト | 10,699.63Mbps | 12,601.33Mbps | 17％ |
| 512 バイト | 17,031.28Mbps | 19,949.23Mbps | 17％ |
| 1518 バイト | 34,609.43Mbps | 40,155.30Mbps | 16％ |
一方、同じ第 3 世代 Xeon Scalable を使用した構成で VIRTIO 1.1 を有効にすると、さらに 9 から 17％の性能向上が報告されています。CPU 世代の更新による性能向上と、VIRTIO バックエンドの最適化による性能向上が、それぞれ別に確認されています。これは、CPU 性能とデータパス設計が代替関係ではないことを示しています。
SR-IOV と DPDK を組み合わせた実測例
NVIDIA の DPDK 24.11 性能レポートにある Test #4 では、KVM 上の VM へ SR-IOV VF を割り当て、ゲスト OS 内の DPDK l3fwd で転送する試験が行われています。この試験では、ConnectX-6 Dx の 100GbE ポートに 1 つの VF を作成し、12 キューを 12 論理コアへ割り当てています。
64 バイトフレームでは 148.81Mpps、128 バイトでは 84.46Mpps、1518 バイトでは 8.13Mpps を記録し、すべてのパケットサイズで 100GbE のラインレートをパケットロスなしで達成しています。これは、SR-IOV と DPDK が競合する選択肢ではなく、組み合わせて使用されることを示す具体例です。
同時に、VF を VM へ割り当てただけで自動的に性能が出るわけではないことも分かります。この試験では、VF への複数キュー割り当て、vCPU とキューの対応、HugePages、CPU 分離、NUMA を意識したメモリー配置、IOMMU パススルーモード、リアルタイム優先度、NIC 固有の調整などが設定されています。SR-IOV の VF がゲスト OS から認識できることと、要求性能を安定して出せることは別です。
既存システムの更新では元の採用理由から検証する
新規システムで SR-IOV を採用するかどうかを考える場合と、既存の SR-IOV 前提システムから SR-IOV を外す場合では、判断の出発点が異なります。既存システムの更新では、まず要件定義書、基本設計書、性能試験結果、製品選定時の資料、ベンダー回答などを確認します。単に「高性能化のため」と書かれているだけでは不十分です。
| 現行 SR-IOV の採用理由 | CPU 更新による再検証 |
|---|---|
| 最大スループット不足 | ソフトウェアパスで再検証する余地がある |
| 小パケット時の pps 不足 | パケットサイズ別に再検証が必要 |
| ホスト CPU 使用量の削減 | コア数と CPU 効率を比較する必要がある |
| レイテンシー短縮 | 平均値だけでなく分布を比較する必要がある |
| ジッター抑制 | 高負荷時を含む変動測定が必要 |
| 他ワークロードとの性能分離 | CPU 性能だけでは代替できない可能性が高い |
| NIC キューや帯域の専有 | データパス設計として再評価が必要 |
| ベンダーサポート条件 | 製品仕様および認定構成の確認が必要 |
古いシステムでは、SR-IOV を採用した理由や当時の性能試験記録が残っていない場合があります。その場合、「理由が分からないため外す」という判断は成立しません。むしろ、現在の SR-IOV 構成で何が実現されているのかを先に測定する必要があります。
測定すべき値には、パケットサイズ別のスループット、パケットサイズ別の pps、ホストおよびゲストの CPU 使用率、パケットロス、平均レイテンシー、99 パーセンタイルや 99.9 パーセンタイルのレイテンシー、ジッター、他 VM の負荷を変化させた場合の性能変動、NUMA をまたいだ場合の性能劣化、障害やフェイルオーバー時の挙動が含まれます。現行構成がどの程度の性能、安定性、分離を提供しているかを把握したうえで、次期システムのソフトウェアデータパスと比較します。
SR-IOV を使用しない判断自体は正しい場合がある
SR-IOV には性能上の利点がありますが、運用上の制約もあります。VF 数や PCI アドレスの管理、NIC モデルへの依存、NUMA を意識した VM や Pod の配置、ライブマイグレーションの制約、障害交換時の対応、NetworkPolicy やオーバーレイネットワークとの統合、監視や障害解析の複雑化、物理 NIC とワークロードの結び付きなどです。
通常の virtio や vhost-user で要求性能を満たせるのであれば、SR-IOV を外すことで運用性や可搬性が改善する可能性があります。そのため、SR-IOV を使用しないこと自体は、性能を軽視した判断ではありません。ただし、その結論は「現行システムで SR-IOV が解決していた要件を確認し、次期システムのソフトウェアデータパスでも同じ条件を満たせることを検証したため、SR-IOV を採用しない」である必要があります。「最新 CPU だから不要」と「要求を満たせることを検証したため不要」では、意味がまったく異なります。
判断すべきなのは CPU の新旧ではなく現行要件を維持できるかである
| 確認項目 | 主な確認内容 |
|---|---|
| 現行の採用理由 | なぜ SR-IOV が必要と判断されたのか |
| 帯域 | 平均値とピーク時に必要な Gbps |
| パケットレート | パケットサイズ別の pps、Mpps |
| パケットサイズ | 実トラフィックの分布 |
| 処理内容 | ルーティング、ACL、NAT、暗号化、DPI など |
| CPU 効率 | 必要コア数と cycles per packet |
| レイテンシー | 平均値とパーセンタイル値 |
| ジッター | 高負荷時の遅延変動 |
| 性能分離 | 他 VM や Pod から受ける影響 |
| NUMA | NIC、CPU、メモリーの配置関係 |
| 障害条件 | NIC、キュー、コア障害時の挙動 |
| 製品条件 | ベンダーの認定構成やサポート条件 |
| 運用性 | 移行、監視、障害解析、交換手順への影響 |
CPU の世代は、この表の一項目にすぎません。CPU が新しくなることは、ソフトウェアデータパスの再検証を行う理由にはなります。しかし、検証を省略する理由にはなりません。
まとめ
既存の SR-IOV 前提システムを更新するとき、「新しい CPU は高速なので、SR-IOV は必須ではない」と考えることがあります。その可能性自体は否定できません。現行システムで SR-IOV が採用された理由が、当時の CPU やソフトウェアデータパスでは必要なスループットや pps を実現できなかったことだけであれば、次期システムでは SR-IOV を外せる可能性があります。
しかし、現行の採用理由が、レイテンシーの安定性、ジッターの抑制、CPU 効率、性能分離、NIC キューの専有、予測可能性などにあった場合、CPU 性能の向上だけでは代替できません。最も危険なのは、元の採用理由を確認せず、スループット不足だけが理由だったと暗黙に仮定することです。
CPU 性能の向上は、既存の処理経路をより速く実行できるようにします。SR-IOV は、物理 NIC から VM や Pod までの処理経路を変えます。DPDK は、NIC キュー、DMA バッファー、CPU コアを使用するパケット処理モデルを変えます。これらは同じ問題を解決する技術ではありません。
既存システムの更新で SR-IOV を外すのであれば、判断の出発点は「最新 CPU だから」ではなく、現行システムで SR-IOV が担っていた要件を、新しいデータパスでも同等以上に満たせることを確認したか、という問いであるべきです。確認できているのであれば、SR-IOV を外すことは合理的な設計変更です。確認していないのであれば、それは技術刷新ではなく、既存の設計前提を根拠なく捨てているだけです。
参考資料
- The Linux Kernel Documentation – VFIO
- DPDK Programmer’s Guide – Poll Mode Driver
- DPDK Programmer’s Guide – Packet mbuf Library
- Intel – SR-IOV for NFV Solutions: Practical Considerations and Thoughts
- NVIDIA – NVIDIA NICs Performance Report with DPDK 24.11
- Open vSwitch Documentation – DPDK vHost User Ports
- Intel – Open vSwitch Optimized Deployment Benchmark Technology Guide
