DPDK：ユーザースペースでのパケット処理を適切に計画する

DPDKの基本原理と正しい位置づけ

DPDK これは、ユーザースペースでネットワークパケットを可能な限りオーバーヘッドを抑えて処理する必要があるアプリケーション向けのフレームワークです。 カーネルのネットワークスタックやソケット、そのパケット構造を経由する通常の方法の代わりに、アプリケーションは選択したネットワークカードを自身のデータパスに直接利用することができます。これは主に、高いパケットレート、低いレイテンシ、および多数の小さなパケットに対する計画性の高い処理を目的としています。

ここで「カーネルの制限なし」という表現は簡略化されたものです。Linuxカーネルは、オペレーティングシステム、メモリ管理、プロセス、セキュリティ、および数多くの管理タスクのために引き続き存在します。 また、DPDKは、ネットワークカードの制限や、PCIe、メモリ帯域幅、CPUの制限を置き換えるものでもありません。DPDKは、バインドされたインターフェースにおいて、主に通常のカーネルデータパスをバイパスし、パケット処理を専用のアプリケーションに移行させるものです。

通常のLinuxネットワークパスでは、ネットワークドライバ、NAPI、パケット処理、およびソケット層が連携して動作します。このパスは、一概に純粋な割り込みベースというわけではありません。DPDK-Poll Mode Driver ユーザースペースから直接受信キューを照会します。アプリケーションはパケットをグループ単位で受け取り、検証または変更を行った後、送信キューまたは次の処理段階に渡します。

これは一般的なカーネルチューニングではなく、TCP接続数が少ない通常のWebアプリケーションにおいては、たいてい最初に講じる対策ではありません。 L4ロードバランシング、フィルタリング、あるいはトンネルのエンドポイントなど、パケットのデータパス自体が明らかにボトルネックとなっている場合にのみ、得られる可能性のあるパフォーマンス向上が追加の運用コストを正当化することになります。 バージョンに依存する特性については、実際に使用されているリリースタグのドキュメントと照らし合わせて確認する必要があります。なお、リリース候補版（Release Candidate）は、本番環境で運用されているリリース版と同等とはみなされません。

ユーザースペースのパッケージパスの仕組み

入力側で、アプリケーションはネットワークカードの1つまたは複数のRxキューを設定します。割り当てられた実行コアは、ループ内でキューをポーリングし、利用可能なパケットのバーストを受け取ります。これらは バースト処理 パケットごとの関数呼び出しと管理負荷を軽減します。分類、転送、または変更の後、アプリケーションはパケットを一括してTxキューに格納します。

ポーリングは、負荷の高いデータパスにおける頻繁な割り込みの切り替えを回避し、コアの動作をより予測しやすくします。 その代償として、CPUは常にアクティブな状態になります。キューが空であっても、lcoreは新しいパケットの有無を引き続きチェックし続けるからです。そのため、このモデルは、トラフィックがまばらだったり大きく変動したりするインターフェースよりも、常に高い負荷がかかる環境に適しています。

パッケージデータとメタデータは rte_mbuf-オブジェクト。これらは事前に作成されたメモプールから取得され、パケット長、入力ポート、オフロード情報、および必要に応じてRSSハッシュなどが含まれています。事前に予約されたプール、固定されたキューとカーンの割り当て、そして短い処理パスは、 キャッシュの局所性 また、不必要な共通データ構造を避ける。

ただし、ゼロコピーはDPDKの自動的な機能ではありません。データがコピーされるかどうか、またどこでコピーされるかは、NIC、ドライバ、オフロード機能、およびアプリケーションロジックによって異なります。 大きなフレームやセグメント化されたフレームは、複数の連結されたmbufで構成される場合があり、これはジャンボフレームの場合などに該当します。パケットデータの再構成、結合、あるいは互換性のないバッファ間での転送を行う場合は、自身のデータパスにおけるメモリ移動の可能性を考慮する必要があります。

建築、資源、そして厳しい制約

環境抽象化レイヤー（Environment Abstraction Layer）、略して EAL, DPDKを初期化し、メモリの予約、デバイスへのアクセス、タイマー、および論理コアの割り当てなどを提供します。これに基づき、アプリケーションはイーサネットキュー、メモリプール、およびそれらの処理を設定します。 ここでいう「lcore」とは、DPDK用に割り当てられた論理コアであり、単に自由に移動するアプリケーションスレッドではありません。これらの基本的なEALの特性については、DPDK 25.07のドキュメントで裏付けられています。バージョンに依存する詳細については、使用するリリースタグごとに別途確認する必要があります。

データパスが直線的な場合、多くの場合、1つのカーネルがパケットの受信から判定、送信に至るまでの全処理を完結させます。この「ラン・トゥ・コンプリート」モデルにより、カーネル間の引き継ぎが回避されます。 一方、パイプラインでは、たとえばパーサー、フロー検索、転送といった処理が段階的に分離されます。これにより責任範囲を整理できますが、各段階間にループや同期処理が生じ、メモリ局所性が低下する可能性があります。

設計においては、NUMAにも配慮する必要があります。データパスが他のCPUソケット上のメモリに頻繁にアクセスすることにならないよう、キュー、lcore、およびパケットプールは可能な限り同じNUMAノード上に配置すべきです。 また、達成可能なパフォーマンスは、NICの機能、PCIe接続、メモリ帯域幅、CPUクロック、パケットサイズ、および各パケット処理の複雑さにも左右されます。

L4ロードバランサーは、DPDKのIPおよびポート情報を用いて、迅速に評価を行い、フローを割り当て、パケットを転送することができます。しかし、それによってTLSターミネーション、複雑なNATステート、ロギング、ヘルスチェック、あるいは処理速度の遅いバックエンドが自動的に高速化されるわけではありません。 同様に、コントロールプレーンも、設定、テレメトリ、エラー処理のために利用可能なCPU時間を必要とします。したがって、DPDKは明確に区切られたデータパスを高速化しますが、必ずしもサービス全体を高速化するわけではありません。

パケットバッファのサイズと有効期間もアーキテクチャの一部です。メンプールは、同時に利用可能なバッファの数を制限しますが、アプリケーション側は所有権の移行を適切に管理する必要があります。 プールのサイズが小さすぎると、負荷がかかった際に枯渇する恐れがあり、逆に大きすぎるとメモリを無駄に消費することになります。適切なサイズは、キュー、バーストサイズ、パケットパス、および予想される負荷のピークに基づいて決定されるものであり、普遍的な基準から導き出されるものではありません。

DPDKを使用する前に前提条件を確認する

DPDKの導入計画は、ハードウェア、メモリ、およびCPUの割り当てが適切に整合して初めて立てられる。 インストールだけでは高性能なデータパスは実現できません。PMDは具体的なNICモデルに対応している必要があり、アプリケーション用にリソースを予約できる必要があります。以下の検証では、技術的な最低要件と、実際に導入されたデバイスにのみ適用される前提条件とを区別します。

Hugepagesは、大規模なパケットプールでは一般的な手法ですが、すべてのDPDKアプリケーションにおいて例外なく必須というわけではありません。EALは–no-hugeもサポートしています。 この特別モードは、標準的な推奨事項と同等のものではありません。パイロット運用を開始する前に、適合性、メモリ管理、およびドライバの制限を確認する必要があります。ここで使用されているシステムおよびEALの基礎知識については、DPDK 25.07に記述されています。また、実際にインストールされているリリースとの互換性についても確認してください。

特に深刻なのは、 デバイスの紐付け. 多くのPMDでは、対象のNICが通常のカーネルドライバから切り離され、例えば vfio-pci バインドされます。これにより、通常のLinuxネットワークスタックからは、そのインターフェースが通常通り利用できなくなります。ただし、具体的な手順はPMDに合わせて設定する必要があり、サポートされているすべてのネットワークカードに一律に適用することはできません。

重要な例外として、分岐型PMDがあります。ドライバのドキュメントには、このようなPMDは対応するカーネルドライバから解放してはならないと記載されています。この場合、ユーザースペースのデータパスが特定のリソースを使用している間も、カーネルドライバはバインドされたままにしておくことができます。 リンク先のバージョン未指定のドキュメントは、26.11.0-rc1 の開発段階のものであり、26.07 向けのバージョン固有のガイドではありません。実際に使用している PMD のマニュアルで、デバイスのサポート状況や利用可能なカーネルツールを確認してください。

変更を行う前に、以下のステータス照会を実行すると、PCIデバイスとその現在のドライバのバインド状況を確認できます。このコマンド自体はバインドを変更しません。ターゲットシステム上で、インストール済みのDPDKソースまたはツール構造に対応するパスを指定して実行してください。

./usertools/dpdk-devbind.py --status

選択したPMDがカーネルドライバを置き換えない場合でも、管理アクセスと本番データパスを分離してください。SSHまたはコンソールへのアクセス可能性は、パイロット運用中にバインディングやトラフィック配分が変更されるインターフェースに依存してはなりません。 独立した管理インターフェース、アウト・オブ・バンド・アクセス、または事前に検証済みのローカル復旧経路を設けることで、設定ミスのリスクを低減できます。

DPDK、AF_XDP、およびカーネルスタックの比較

データパスの選択は、優劣の順位付けではなく、運用上の判断です。Linuxカーネルスタック、AF_XDP、DPDKは、それぞれ処理負荷、デバイスへのアクセス、CPU消費量に違いをもたらします。 適切な選択肢は、ネットワークパスにおけるパケットレートやレイテンシが実際にボトルネックとなっているのか、それともアプリケーション、暗号化、バックエンドがボトルネックとなっているのかによって決まります。

AF_XDP は、パケットを早期に処理しつつも、Linux のネットワークモデルに忠実であり続けたいチーム向けの中間的な選択肢です。 カーネルは、コピーモードと、ドライバのサポートを前提とするゼロコピーを定義しています。ゼロコピーが明示的に要求された場合、ドライバがこの機能を提供していないと、ソケットの作成に失敗する可能性があります。XDPレイヤーの位置づけについては、以下の記事が参考になります。 XDP および eXpress Data Path.

一方、DPDKはPoll Mode Driversを利用し、アプリケーション側から直接キューを処理します。これにより、DPDKのデータパスにおけるソケットや割り込みの処理を回避できますが、メモリ、キュー、およびカーネル割り当ての管理を自ら行う必要があります。 ゼロコピー これは、一般的な性能保証でもなければ、任意のDPDKパスが自動的に備える特性でもありません。コピー数は、アプリケーション、オフロード、およびメモリ転送によって異なります。

ルーティング、ファイアウォール、可観測性、および運用上の簡便性が、専用のパケットパスよりも重要である場合は、カーネルスタックを選択してください。 カーネル接続によるターゲットを絞った高速化を行う場合は、AF_XDPを検討してください。DPDKは、高いパケットレートや安定したレイテンシが確実に必要とされ、NICのサポートが整っており、追加の運用責任を長期的に担えるチームが存在する場合にのみ、導入する価値があります。

キュー、CPUピンニング、NUMAを適切に計画する

耐久性に優れた キューの割り当て まず、NIC、CPU、メモリ間の近接性から始まります。EALは、論理コアの選択、メモリの予約、およびデバイスの割り当てをサポートしています。 単純なデータパスでは、通常、Rxキューを1つのlcoreに固定的に割り当て、関連するメモリプールをローカルNUMAノード上に作成し、その後、処理を適切なTxキューに引き渡すことが合理的です。 これらの基本的なEALに関する情報は、DPDK 25.07のドキュメントに記載されており、バージョン依存のオプションについては、使用しているリリースタグと照らし合わせて確認する必要があります。

2つのNUMAノードを持つホストの、特定の製品に依存しない例としては、次のようなものが挙げられます。ノード0のNICには2つのRxキューが割り当てられ、ノード0の各lcoreが1つのキューを完全に処理します。 パケットバッファも同様にノード0上に配置されています。もう1つの（ポーリングを行わない）コアは管理タスクのために空き状態として確保され、一方、ノード1は他のサービスや明確に分離されたデータパス用に割り当てられます。

• データパス：各キューに固定で割り当てられたlcore、ローカルメモリプール、および明確に命名されたRx／Txペア。
• 管理：テレメトリ、制御ロジック、イベント、およびOSサービス用にCPUリソースを確保しておく。
• 予備容量：すべてのコアを常にフル稼働させるのではなく、負荷のピーク時、トラブルシューティング、および将来の拡張を見越して、余裕を持たせておく。

Rxキューを複数のlcore間で共有しないでください。 PMDガイドラインでは、RxキューおよびTxキューの分割を推奨していません。これは、分割に必要なグローバルロックがパフォーマンスに深刻な影響を及ぼす可能性があるためです。複数のlcoreによるTxキューへの同時アクセスは、ドライバに以下の機能がある場合に限り、文書化された例外として認められています。 RTE_ETH_TX_OFFLOAD_MT_LOCKFREE と報告されます。具体的なNIC／PMDの組み合わせについて、この機能を確認してください。ポート速度や一般的なオフロードスイッチから推測してはいけません。

パーサー、分類、送信の各段階が分離されたパイプラインは、責任の所在を明確にするのに役立ちます。文書化されたパイプライン方式では、パケットがリングを介して他のコアに渡されるため、余分なメモリアクセスや引き渡しが発生します。 単純なフィルタリングやL4転送の場合、キューごとに「完了まで実行（Run-to-completion）」方式を採用する方が、計画が立てやすいことがよくあります。複数の段階を採用するのは、具体的な負荷プロファイルにおいて、その役割分担による追加のオーバーヘッドが正当化される場合にのみ行うべきです。

また ハードウェアオフロード これらを設計に織り込むことはできない。どのチェックサム、セグメンテーション、RSS、またはフロー機能が利用可能かは、具体的なイーサネット機器とそのPMDの機能によって決まる。設計前にこれらを確認し、オフロード機能がない場合は例外ではなく、通常の設計ケースとして扱うこと。

稼働中のDPDKを安全に監視する

DPDKデータパスの運用には、パケット処理とリソースを総合的に把握するためのメトリクスが必要です。少なくとも、処理済み、破棄済み、およびエラーが発生したパケットの数、ならびに処理レート、メモリプールの空き容量、および レイテンシの分布 単なる平均値だけではなく。利用可能な追加のポート、キュー、またはドライバカウンタの数は、具体的なPMD、NIC、およびアプリケーションによって異なり、使用する組み合わせごとに確認する必要があります。

ポーリングは、意図的な目標の競合です。lcoreは、通常の割り込みパスを経由せずにパケットを処理できるよう、Rxキューを継続的にポーリングします。トラフィックが少ない場合や全くない場合でも、ポーリングループはアクティブなままとなります。 そのため、データパス用lcoreとは別に、制御ロジック、テレメトリ、およびオペレーティングシステム用にCPU容量を確保してください。補足として使用されるEALドキュメントはDPDK 25.07を参照しています。リリースに依存する機能については、インストールされたバージョンで確認してください。

原因分析においては、時間的な相関関係が重要です。パケット損失が、エラーカウンターの増加、メモプール残量の減少、あるいはデータパス lcore の負荷上昇と同時に発生している場合、これらはまず検証可能な手がかりであり、まだ明確な原因の証明にはなりません。 応答時間の変動は、NUMAから離れたメモリ、競合するタスク、パイプラインの引き渡しなどが原因である可能性があります。こうした仮説については、それぞれ、コア割り当て、キューの分布、および同じ時間枠での測定値と比較検討してください。

インターフェースでの高速なキャプチャは、完全かつ永続的で損失のないパケット記録と同義ではありません。 フロー統計やヘッダー解析には、わずかなメタデータで十分な場合もあります。すべてのパケットを保存する場合、さらにストレージ帯域幅、バッファ容量、書き込みスループット、および選択されたストレージメディアがシステム構成を制限します。データ保護と保存規則は、ネットワークスループットでは解決できない独立した要件です。

仮想マシンとコンテナを、独立した統合タスクとして計画してください。具体的なプラットフォームにおいて、デバイスへのアクセス、ストレージ、CPUの割り当て、および必要な権限がどのように提供されるかを確認してください。 サンプルパラメータを一律に適用するのではなく、使用しているPMDでこの組み合わせを検証してください。リンク先のLinuxガイドは現在、開発版26.11.0-rc1に基づいています。本番環境の構築にあたっては、実際にインストールされたリリースのドキュメントを基準としてください。

典型的な不具合を体系的に点検する

トラブルシューティングでは、まず観察可能な症状と考えられる原因を区別する必要があります。ドライバのバインディング、キュー数、メモリパラメータを同時に変更しないでください。そうすると、原因を特定できなくなってしまいます。 非破壊的なカウンタ、設定情報の確認、および影響を受けたキューと影響を受けていないキューの比較を行うことで、通常、介入を行う前に、より信頼性の高い手がかりが得られます。

キューの挙動に異常が見られる場合は、キューの所有者とメモリプールのNUMAノードを確認してください。 Run-to-completionモデルでは、割り当てられたlcoreが受信、処理、送信を処理し、パイプラインがパケットを他のコアに渡します。ただし、Rxキューをlcore間で分割しないでください。Txキューへの同時アクセスは、 RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-この機能は例外として扱われます。ユーザー自身で設定した制限があるため、キュー共有は推奨されるスケーリング戦略とは言えません。

ハードウェアオフロードが利用できない場合、重要なのは単にどのスイッチが設定されているかだけでなく、デバイスとPMDが実際にどのような機能を提供しているかという点です。 アプリケーションは、そのモデルで利用できない機能であっても、希望する機能を計画に組み込んでしまう可能性があります。データパスをそのオフロードに依存させる前に、具体的なNICのサポート状況と、実行時に報告される機能とを照らし合わせて確認してください。

testpmd の結果は、ベースラインまたは機能テストとして位置づけるべきであり、その後のアプリケーションにおける性能の証明として捉えるべきではありません。io-Forwarding モードでは、パケットは変更されることなく転送され、業務処理のためにその内容が評価されることはありません。 このモードでは、パーサー、フローテーブル、NAT、暗号化、およびプロトコル状態は反映されません。リンク先のバージョン未指定のドキュメントは 26.11.0-rc1 に関するものです。インストール済みのリリースのマニュアルで動作を確認してください。 転送モード、パケットサイズ、Rx/Txキュー数、および転送コア数を記録し、実際の処理ロジックとの比較を繰り返してください。

ロールアウト、バージョン管理、および導入の決定

まず、隔離されたテストと、記録された 負荷プロファイル: パケットサイズ、ピーク負荷、フロー数、および必要な処理ステップ。 公式のハードウェア概要およびドライバマトリックスを参照し、具体的なNICと、それに適合するPoll Modeドライバ、および必要な機能を確認してください。リストに掲載されているメーカー名だけでは、すべてのカードやオフロード機能が保証されるわけではありません。その後、転送例だけでなく、実際のアプリケーションロジックを用いてテストを行ってください。

各テストごとに、DPDKのバージョン、ファームウェア、ドライバ、カーネル、および設定を記録してください。 アップデートを行う前に、対象とする正確なリリースタグのリリースノートを読み、自身のデータパスに関連する変更点を記録してください。リリースごとに機能や制限事項が変更される可能性があるため、異なるバージョンのリリースノートはこの対応付けの代わりにはなりません。

DPDK 26.07のリリースノートに記載されている具体的な確認事項の一つは、メモプールキャッシュのフラッシュ／リフィルアルゴリズムの変更です。これにより、その実効サイズは設定サイズと一致するようになりました。以前は設定サイズより50％大きくなっていました。 各lcoreが特定のMempoolからオブジェクトを「取得のみ」または「返却のみ」行う場合に限り、リリースノートでは、キャッシュミス率の2倍化を防ぐために、設定されたキャッシュサイズを2倍にすることを推奨しています。 これは、RxとTxのlcoreが分離されているパイプラインなどに該当し、Run-to-completion全般に当てはまるわけではありません。この変更はリリース26.07に関するものであり、リンク先の過去のリリースページは現在、26.11.0-rc1のドキュメント内に掲載されています。

まずは限定的なパイロット運用から始め、明確な中止基準を設定してください。従来の運用環境と同等の条件下で、スループット、高レイテンシのパーセンタイル、パケット損失、およびCPU使用量を比較してください。 監視、再起動、および以前の設定へのロールバックについて検証する。運用コストを考慮すること。これだけでは、一般的なスループットの保証を導き出すことはできない。

DPDKの導入は、測定されたメリットが追加の保守コストを正当化できる場合に、特に有効である。周辺システムプラットフォームとの位置づけについては、本記事で補足している。 ホスティング環境におけるLinuxカーネル 計画。通常のホスティングサービスについては、テストの際に比較の基準として既存のネットワークパスも残しておいてください。