はじめに
Day5〜Day7 では、virtio-net → vhost-net → vhost-user → SR-IOV / PCI Passthrough と、KVM のネットワークスタックが辿る高速化パスを整理してきました。
どの方式も「virtio アーキテクチャの最適化」や「NIC を直接 VM に渡す」といった進化でしたが、Day8 で扱う DPDK（Data Plane Development Kit） は、そもそもの発想が異なります。
DPDK は、Linux カーネルのネットワーク処理を完全に迂回し、ユーザー空間アプリケーションが NIC を直接制御する 世界を実現します。
virtqueue も vhost も softirq も TCP/IP スタックも存在しません。
DPDK を理解することは、ネットワーク処理そのものの本質を理解することに近く、NFV（仮想ルーター/ファイアウォール）などの高速パケット処理世界には欠かせない技術へと結びつきます。
DPDK は仮想化固有の技術ではない
DPDK は「仮想ネットワークを高速化するための仕組み」という誤解がよくありますが、本質は 「NIC をカーネルから切り離し、ユーザー空間で直接パケット処理を行うための基盤」 です。
そのため DPDK は仮想化の有無に依存しません。以下のどれでも動作し、アーキテクチャ上の狙いは一貫しています。
- ベアメタル + 物理 NIC（最も純粋な構成）
- VM + SR-IOV / Passthrough で渡した NIC
- vhost-user と組み合わせた高速仮想 NIC
- コンテナ内で DPDK アプリ
DPDK を使う際の基本は次のとおりです。
- 対象 NIC をカーネルネットワークスタックから切り離す
- vfio-pci / uio などユーザー空間対応ドライバへバインドする
- アプリケーションが NIC のキューを直接操作してパケット I/O
つまり、DPDK の役割は「仮想化を高速化する技術」ではなく、カーネルネットワークスタックをバイパスして NIC の生性能をユーザー空間へ届けることにあります。
仮想化技術（virtio / vhost-user / SR-IOV）と組み合わせることで、それぞれの構造上の制約を補い、より高いパフォーマンスを引き出せるだけです。
DPDK とは何か
通常のパケット処理は次のように、NIC → カーネル → アプリという長い経路を辿ります。
NIC → kernel driver → softirq → qdisc → TCP/IP → socket → アプリDPDK はこの経路を丸ごと捨てます。
NIC → VFIO/UIO → DPDK PMD（ユーザー空間ドライバ）→ アプリLinux が提供するネットワークスタック（ソケット・TCP/IP・softirq・qdisc）を一切使わず、アプリケーション内部でパケットを直接処理します。
このため、同じネットワークでも、Linux networking とはまったく異なる別種のプロセッサアーキテクチャに変わります。
DPDK を支える 4 つの基盤技術
DPDK は「高速に動く」から評価されているのではなく、そもそもカーネルネットワークとはまったく別の構造だから速いという点が本質です。
この構造を支える基盤が次の 4 つです。
Hugepage（ヒュージページ）
巨大で連続したメモリ領域を確保し、NIC の DMA が断片化に邪魔されず、最短経路でアプリと直接やり取りできるようにする仕組み。DPDK アプリは hugepage 上に ring buffer（パケットプール）を作り、そこへ NIC が直接 DMA を行います。
VFIO / UIO（ユーザー空間ドライバ）
DPDK は NIC を「OS ではなくアプリ自身で扱う」必要があるため、通常の kernel driver ではなく VFIO/UIO を使って NIC を直接掴むようにします。これは SR-IOV や PCI Passthrough で VM が NIC を掴む構造と非常に似ています。
ゼロコピー
DPDK のパケット処理は基本的にコピーが発生しません。NIC → hugepage → DPDK app という単一のバッファリングで処理できます。virtio のような bounce buffer や抽象化レイヤのコピーは存在しません。
Polling（ポーリング）モデル
DPDK は「割り込み」を使いません。CPU コアをアプリ専用に固定（ピニング）し、その CPU が NIC をずっと見張り続けるモデルです。
このため、以下がゼロになり、遅延のバラつきがほぼ消えます。
- IRQ handler のオーバーヘッド
- コンテキストスイッチ
- スケジューラの介入
DPDK のデータパス（virtio 系との決定的違い）
通常の KVM（virtio / vhost）データパス：
NIC → kernel driver → softirq → vhost → virtqueue → QEMU → VMSR-IOV / Passthrough データパス：
NIC → VM（VF / 物理 NIC）DPDK データパス（最短）：
NIC → DPDK（ユーザー空間）→ アプリこのように、DPDK の処理経路は他のどの方式よりも短くなります。
特に重要なのは、DPDK では以下が存在しません。つまり、ネットワーク処理は OS の守備範囲から完全に消えます。
- virtqueue
- vhost
- softirq
- qdisc
- socket
- スケジューラ介入
DPDK が高速な理由
DPDK の速度が桁違いなのは、最適化の積み重ねではありません。抽象化を捨てた結果、速度が副作用として生まれているだけです。
割り込みを使わずポーリングにしたから
割り込みは OS を介在させる最大のボトルネックです。DPDK は IRQ を完全否定し、「CPU を NIC の忠実な召使い」にします。注意点として、PMD として割り当てた CPU コアは、パケットが来ていなくても CPU 使用率は常に 100% になります。
パケットが hugepage に直接 DMA されるから
カーネルや virtio のような中間バッファがなく、全てのパケットはアプリケーションが専有するメモリへ一直線に到達します。
カーネル処理（softirq / qdisc / TCP/IP）が全て排除されているから
Linux のネットワークスタックは汎用性のために複雑です。DPDK はこれらを全て捨て、アプリ側で必要なものだけを実装します。
CPU コアを専属スレッド化するから
DPDK app はスケジューラの外側で動作し、CPU はその処理だけを行います。これにより、レイテンシはほぼ物理限界へ収束します。
virtio / vhost / SR-IOV / Passthrough と DPDK の関係
実は、DPDK は virtio 系高速化の延長線にある技術ではありません。共通点は「高速化を目指す」という目的だけです。関係性を整理すると次のようになります。
virtio / vhost と DPDK
- DPDK は virtio を使わない世界が基本
- 但し、virtio-pmd を使えば DPDK で virtio 処理も可能
- vhost-user を DPDK ベースで提供するケースもある（OVS-DPDK）
SR-IOV / PCI Passthrough と DPDK
性能面ではこの組み合わせが最強です。
- NIC を直接 VM に割り当て（VF / passthrough）
- VM 内でその NIC を DPDK で直接操作
virtio を完全に捨てた最短のパスを構築し、物理ネットワーク機器に限りなく近い NFV が実現します。
DPDK の用途
DPDK は高速という言葉だけが独り歩きしがちですが、本質的にはハンマーではなく外科手術用のメスのような技術です。
DPDK を使うべき典型例
- 仮想ルーター / 仮想ファイアウォール（NFV）
- IPS / IDS
- パケットインスペクション
- ロードバランサ（L4）
- IoT ゲートウェイ
- VPN / トンネル処理
- SmartNIC 代替
DPDK が不要なケース
- Web / DB / アプリケーションサーバー
- Kubernetes ノードの一般コンテナ
- バッチシステム
- 通常 VM のネットワーク
DPDK は CPU を独占し、運用コストも重く、速度が存在意義となるアプリにしか意味がありません。
DPDK の実装難易度の本質
DPDK はしばしば「パケット処理を高速化するライブラリ」として扱われますが、その本質は OS が担うネットワーク処理をユーザー空間で再構成するための基盤にあります。この性質が、DPDK の特殊な難しさの根源です。
OS のネットワーク機能をアプリ側が引き受ける世界
Linux のネットワークスタックは、次のような大規模な機能を自動的に提供しています。
- 割り込みによるパケット受信
- softirq / qdisc によるスケジューリング
- TCP/IP 処理
- メモリ管理と再送制御
- キューイングやフロー制御
DPDK を利用すると、これらを OS ではなくアプリケーションが担うことになります。
つまり、DPDK アプリを書くという行為は、「NIC → 受信 → 解析 → 処理 → 送信」の全工程をユーザー空間で構築することとほぼ同義です。
これは一般的なプログラミングではなく、小規模なネットワーク OS を作る作業に近い設計思想を要求します。こうした「OS 機能を肩代わりする構造」こそが、DPDK が他の技術と比べて異質に見える理由です。
インフラ分野で DPDK アプリを自作する必要はほとんどない
インフラエンジニアが DPDK アプリケーションそのものを書くケースは極めて稀です。現実的には、DPDK を内部で利用する既存コンポーネントを適切に配置・運用することが役割になります。
主な例は次のとおりです。
- OVS-DPDK（仮想スイッチ高速化）
- VPP（Vector Packet Processing）
- FD.io の各種データプレーン
- DPDK 対応ロードバランサー / IDS / IPS
- SmartNIC / P4 NIC
- SR-IOV + VM 内の DPDK アプリケーション
インフラ側が担うべきは、「DPDK を書くこと」ではなく「DPDK を理解し、どこに・どのように組み込むかを設計すること」です。
DPDK アプリ開発が別世界と言われる理由
DPDK アプリの開発には、通常のネットワークプログラミングでは触れない領域が必須になります。
- hugepage / NUMA と密接に連動したメモリ管理
- NIC キューや RSS、PMD の直接制御
- lockless ring buffer を用いた並列処理
- TX/RX フロー制御の自作
- スケジューラ非依存の専属 CPU コア運用
- IRQ を使わないポーリングモデルの設計
これらは「Linux のネットワーク API を使う」世界とは完全に異なり、データプレーンを自分で作り直す作業 です。
このため、DPDK アプリ開発はアプリケーション開発というより、ネットワーク OS 開発の一部であり、専業領域として分化しています。
インフラにとっての DPDK の価値
インフラエンジニアに求められるのは、DPDK という技術の核心を理解し、次のような構成判断ができることです。
- どこから先の処理を DPDK に任せるべきか
- SR-IOV / Passthrough / vhost-user のどれを組み合わせるべきか
- NUMA / CPU ピンニング / hugepage の正しい配置
- OVS-DPDK や VPP をどう配置するか
DPDK を理解しているだけで、ネットワーク仮想化の設計の精度は一段上がります。DPDK は「アプリを高速化するための道具」ではなく、データプレーンそのものを再定義する技術だからです。
まとめ
DPDK は Linux Networking の延長線上にはなく、「パケット処理という行為そのものを再設計する」ための世界です。この別世界のデータ平面を、SR-IOV や Passthrough と組み合わせることで、仮想化環境においても物理限界に極めて近い性能が得られます。
DPDK は Linux が積み上げてきた汎用ネットワークスタックとは異なる、まったく別種のデータプレーンを構成します。
- カーネルを使わない
- virtio も使わない
- vhost も使わない
- socket もない
- 割り込みもない
- キュー（virtqueue）もない
- スケジューラも介在しない
NIC とアプリが直接つながることで、パケット処理という行為そのものを再定義します。
SR-IOV / Passthrough と組み合わせた場合、DPDK は NIC の性能を限りなく 100% に近い形で引き出すことができます。
