ネットワーク通信のコアテクノロジを探索し、TCPIP ユーザーモードプロトコルスタックを手動で作成して、パフォーマンスを向上させます。

1. DPDK の概要

DPDK (データプレーン開発キット) は、高性能データプレーンアプリケーションを迅速に開発するための C 言語ライブラリとドライバーのセットを提供するオープンソースデータプレーン開発キットです。DPDK はユーザー空間を使用してネットワークパケット処理を実装するため、従来のカーネルモードとユーザーモード間の頻繁な切り替えによって引き起こされるパフォーマンスの損失を回避します。

DPDK はさまざまなハードウェアプラットフォームとオペレーティングシステムをサポートし、さまざまなシナリオで優れたパフォーマンスを発揮します。たとえば、クラウドコンピューティング、電気通信、金融、オンラインゲームなどの業界では、DPDK は高速ネットワークデータ処理、仮想化ネットワーク機能、SDN で広く使用されています。

2. DPDKの主な目的

DPDK の主な目的は、開発者が高性能のネットワークアプリケーションを簡単に構築できるように、高速、効率的、柔軟なデータプレーン開発フレームワークを提供することです。具体的には、DPDK は次の問題に対処します。

\1. パケット処理パフォーマンスの向上: ユーザー空間や最適化アルゴリズムなどの技術的手段を使用することで、DPDK はパケット処理パフォーマンスを大幅に向上させ、数百万 pps (パケット/秒) のレベルに達することができます。
\2. さまざまなハードウェアプラットフォームとオペレーティングシステムをサポート: DPDK は、さまざまな一般的なハードウェアプラットフォームとオペレーティングシステムをサポートし、他のオープンソースプロジェクト (Open vSwitch、OpenStack など) と統合できます。
\3. 使いやすい API の提供: DPDK は使いやすい C 言語 API のセットを提供し、開発者が高性能のネットワークアプリケーションを簡単に作成できるようにします。
\4. さまざまなシナリオでアプリケーションをサポート: DPDK は、その高いパフォーマンスと柔軟性により、高速ネットワークデータ処理、仮想化ネットワーク機能、SDN などを含むクラウドコンピューティング、電気通信、金融、オンラインゲームなどの業界で広く使用されています。

3. 労働環境

DPDK の環境抽象化レイヤーは、基礎となる環境の詳細をアプリケーションや関数ライブラリから隠すため、あらゆるプロセッサに拡張できます。オペレーティングシステムに関する限り、Linux と FreeBSD がサポートされています。

市場に関して言えば、ビジネスユーザーの数が増えるにつれて、dpdkを使用する企業はますます増え、dpdkをしっかり学ぶことは、優れたインターネット企業や大手メーカーに入社するための方向性にもなります。dpdk の学習に関しては、Java 中心のビジネスとは異なり、基盤となる技術の理解、コンピュータ原理の基礎の学習の程度、学歴がより重視されます。

これを一言で説明すると、ビジネスとはほとんど関係がありませんが、基盤となるテクノロジーには多くの関係があります。

4.動作原理

DPDK は、パケットを処理するために割り込みの代わりにポーリングを使用します。データパケットを受信すると、DPDK によってオーバーロードされたネットワークカードドライバーは、割り込みを通じて CPU に通知するのではなく、データパケットをメモリに直接保存し、DPDK が提供するインターフェイスを通じて直接処理するアプリケーション層ソフトウェアを配信します。 CPU の割り込み時間とメモリのコピー時間が長くなります。

DPDK の仕組み:

初期化: アプリケーションが開始されると、DPDK は必要なすべてのハードウェアデバイス、スレッド、メモリプール、その他のリソースを初期化し、各 CPU コアに独立した動作環境を割り当てます。
データの受信: データパケットがネットワークカードに到着すると、DPDK はそれをリングバッファーにバッファリングし、新しいデータが到着したことをアプリケーションに通知します。
パケット分類: アプリケーションは、事前定義されたルール (トラフィック監視、負荷分散、セキュリティ検査など) に従ってデータパケットを分類し、対応するキューに送信します。
データパケット処理：DPDKは、キューから処理対象のデータパケットを取り出し、ユーザー空間ドライバー（ユーザー空間ドライバー）を使用して、データパケットの解析、プロトコル変換、ビジネスロジック処理などの処理を実行します。
パケット送信: 処理が完了すると、DPDK は結果をネットワークメッセージに再パッケージ化し、ネットワークカードを介してネットワークに送り返します。
リソースの再利用: アプリケーションが特定のリソースを必要としなくなった場合、DPDK はそれらのリソースをメモリプールまたはハードウェアデバイスに解放して、他のスレッドまたはプロセスで使用できるようにします。

4.1技術原理とアーキテクチャ

ソフトウェア転送およびソフトウェアスイッチングテクノロジの使用により、単一サーバーの内部転送機能が NFV システムの主なパフォーマンスのボトルネックになります。さまざまな高速転送 NFV アプリケーションでは、データパケットがネットワークカードから受信され、処理のために仮想化ユーザーモードアプリケーション (VNF) に送信されます。プロセス全体は、CPU 割り込み処理、仮想化 I/O、およびアドレスマッピングを通過する必要があります。変換、仮想スイッチング層、ネットワークプロトコルスタック、カーネルコンテキストスイッチング、メモリコピー、その他多くの時間のかかる CPU 操作と I/O 処理リンク。

業界では通常、大量の割り込みの排除、カーネルプロトコルスタックのバイパス、メモリコピーの削減、CPU マルチコアタスク共有、Intel VT などのテクノロジーを使用して、一般のユーザーには困難なサーバーデータプレーンのパケット処理パフォーマンスを包括的に向上させています。マスターする。業界は、優れたユーザー開発およびビジネス統合環境を提供しながら、包括的なパフォーマンス最適化ソリューションを緊急に必要としており、DPDK アクセラレーションテクノロジソリューションはその典型的な代表となっています。

DPDK はオープンソースのデータプレーン開発ツールセットであり、ユーザー空間で効率的なデータパケット処理ライブラリ機能を提供します。これは、環境抽象化レイヤーを介してカーネルプロトコルスタックをバイパスし、ポーリングモードでのメッセージの中断のない送受信、および最適化を行います。メモリ/バッファリングエリア/キュー管理、ネットワークカードマルチキューやフロー識別による負荷分散などにより、x86プロセッサアーキテクチャによる高性能メッセージ転送機能を実現しており、ユーザーはさまざまな高速転送アプリケーションを開発できます。 Linux ユーザーモードスペースは、さまざまな商用データプレーンアクセラレーションソリューションとの統合にも適しています。

Intel は 2010 年に DPDK テクノロジーのオープンソースプロセスを開始し、開発者にサポートを提供するために、同年 9 月に BSD オープンソースライセンス契約を通じてソースコードソフトウェアパッケージを正式にリリースしました。オープンソースコミュニティの参加者は、DPDK の技術革新と急速な進化を大きく推進し、現在では SDN および NFV の主要なテクノロジーに発展しました。

4.2 主な特徴

OSカーネルに基づくデータ転送のデメリットは何ですか

割り込み処理。ネットワークに大量のデータパケットが到着すると、ハードウェア割り込み要求が頻繁に発生し、優先度の低いソフト割り込みやシステムコールの実行プロセスが中断される可能性があります。
メモリコピー。通常の状況では、ネットワークデータパケットはネットワークカードからアプリケーションプログラムまで次のプロセスを通過する必要があります。データはネットワークカードから DMA を通じてカーネルによって開かれたバッファに転送され、その後カーネル空間からアプリケーションプログラムにコピーされます。 Linux カーネルプロトコルスタックのユーザーモード空間では、この時間のかかる操作はデータパケットの処理フロー全体の 57.1% を占めます。
コンテキストスイッチ。頻繁に到着するハードウェア割り込みとソフト割り込みは、いつでもシステムコールの実行をプリエンプトする可能性があり、大量のコンテキストスイッチングオーバーヘッドが発生します。また、マルチスレッドのサーバ設計フレームワークでは、スレッド間のスケジューリングにより頻繁なコンテキスト切り替えのオーバーヘッドが発生し、同様にロック競合によるエネルギー消費も非常に大きな問題となります。
ローカル障害。現在の主流のプロセッサには複数のコアがあり、データパケットの処理が複数の CPU コアにまたがる場合があります。たとえば、データパケットは cpu0 で中断され、カーネル状態の処理は cpu1 で、ユーザー状態の処理は cpu2 で行われる可能性があります。複数のコアがあると、CPU キャッシュ障害や局所的な障害が発生しやすくなります。NUMA アーキテクチャの場合、メモリへのクロス NUMA アクセスが発生し、パフォーマンスに大きな影響を与えます。
メモリ管理。従来のサーバーのメモリページは 4K で、メモリアクセス速度を向上させ、キャッシュミスを回避するには、キャッシュ内のマッピングテーブルのエントリを増やすことができますが、これは CPU の検索効率に影響します。

これらの問題に対応して、検討できる技術的なポイントは次のとおりです。

制御層とデータ層は分離されています。データパケットの処理、メモリ管理、プロセッサのスケジューリングなどのタスクはユーザー空間に転送されて完了しますが、カーネルは制御命令の一部の処理のみを担当します。このようにすることで、前述したシステム割り込み、コンテキスト切り替え、システムコール、システムスケジューリングなどの問題は発生しません。
マルチスレッドテクノロジの代わりにマルチコアプログラミングテクノロジを使用し、CPU アフィニティを設定してスレッドと CPU コアを 1 対 1 にバインドし、相互間のスケジュール切り替えを軽減します。
NUMA システムの場合は、クロスメモリアクセスを避けるために、CPU コアが常駐する NUMA ノードのメモリを使用するようにしてください。
キャッシュミスを減らすために、通常のメモリの代わりに巨大なページメモリを使用します。
ロックフリー技術を使用して、リソース競合の問題を解決します。

DPDK の構造は次の図に示されており、関連する技術原則は次のように要約されています。

この図では、下部のカーネル状態 (Linux カーネル) に DPDK の 2 つのモジュール (KNI と IGB_UIO) があります。その中で、KNI は、従来の Linux ネットワークツール (ethtool、ifconfig など) に加え、Linux カーネルモードを使用したプロトコルスタックをユーザーに提供します。IGB_UIO (igb_uio.ko および kni.ko.IGB_UIO) は、UIO テクノロジを使用して、初期化中にネットワークカードハードウェアレジスタをユーザーモードにマップします。

図に示すように、DPDK の上位レベルのユーザーモードは、主にコアコンポーネントライブラリ (Core Libraries)、プラットフォーム関連モジュール (Platform)、ネットワークカードポーリングモードドライバーモジュール (PMD-Natives&Virtual)、 QoS ライブラリ、メッセージ転送分類アルゴリズム (Classify) およびその他の主要なカテゴリ。ユーザーアプリケーションはこれらのライブラリを二次開発に使用できます。以下に簡単に紹介します。

UIO (Linux Userspace I/O) は、アプリケーションスペースでドライバーサポートを提供します。つまり、ネットワークカードドライバーはユーザースペースで実行され、ユーザースペースとアプリケーションスペースでのメッセージの複数のコピーが削減されます。図に示すように: DPDK は、Linux カーネルのネットワークドライバーモジュールをバイパスし、頻繁なメモリコピーやシステムコールを必要とせずに、ネットワークハードウェアからユーザー空間に直接到達します。公式データによると、DPDK ネイキッドパッケージバウンスにはパッケージあたり 80 クロックサイクルが必要ですが、従来の Linux カーネルプロトコルスタックではパッケージあたり 2k ～ 4k クロックサイクルが必要です。DPDK は、仮想化されたネットワークデバイスのデータ収集効率を大幅に向上させることができます。

DPDK を使用しない場合と使用する Linux カーネルの比較

UIO テクノロジーの仕組み:

UIO テクノロジは、デバイスドライバをユーザー空間ドライバとカーネル空間ドライバの 2 つの部分に分割します。カーネル空間ドライバは主に、デバイスリソースの割り当て、UIO デバイスの登録、および割り込み応答機能の一部を担当します。ドライバの作業のほとんどは次のとおりです。ユーザースペースのドライバーの下で完了します。UIOフレームワークが提供するAPIインターフェースを介してUIOドライバをカーネルに登録します登録完了後、デバイスの物理アドレスなどの情報を含むマップファイルが生成されますデバイスのメモリ空間を直接操作できます. UIO テクノロジーにより、アプリケーションはユーザー空間ドライバーを通じてデバイスのメモリー空間を直接操作できるようになり、カーネルバッファーおよびアプリケーションバッファー内のデータの複数のコピーが回避され、データ処理効率が向上します。

簡単に言うと、DPDK を使用すると、高速パケットネットワーキングアプリケーションの開発が高速化されます。つまり、カーネルバイパスのおかげで、パケットをより高速に処理できるアプリケーションを構築できるようになります。実際、通常のネットワーク層パスやコンテキストスイッチパスの代わりに高速パスが使用されます。パッケージはユーザースペースに直接配信されます (生のパッケージとして)。次の図は、Linux カーネルパッケージの処理と dpdk パッケージの処理の違いを示しています。

Linuxカーネル処理パッケージ

dpdk処理パッケージ

低速パスと高速パスの比較

コアコンポーネントライブラリ

このモジュールで構成される動作環境は Linux 上に構築され、環境抽象化層 (EAL) の動作環境を通じて初期化されます。これには、HugePage メモリ割り当て、メモリ/バッファ/キュー割り当てとロックフリー操作、CPU アフィニティバインディングなどが含まれます。 ;第 2 に、EAL は、オペレーティングシステムカーネルと基盤となるネットワークカード間の I/O 操作のシールドを実現し (I/O はカーネルとそのプロトコルスタックをバイパスします)、DPDK アプリケーションに一連の呼び出しインターフェイスを提供し、UIO または VFIO を使用します。 PCI デバイスアドレスへのテクノロジはユーザー空間にマッピングされるため、アプリケーションの呼び出しが容易になり、ネットワークプロトコルスタックやカーネルの切り替えによって引き起こされる処理の遅延が回避されます。さらに、コアコンポーネントには、メッセージ処理に適したメモリプールの作成、バッファ割り当て管理、メモリコピー、タイマー、リングバッファ管理などが含まれます。

DPDK には主に 6 つのコアコンポーネントがあります。

1.環境抽象化層 (EAL) : 特定のプラットフォーム機能を保護するために、他の DPDK コンポーネントおよびアプリケーションに統一インターフェイスを提供します環境抽象化層によって提供される機能には、主に次のものが含まれます: DPDK のロードと起動、マルチコアおよびマルチスレッドのサポート実行タイプ、CPU コアアフィニティ処理、アトミック操作およびロック操作インターフェイス、クロックリファレンス、PCI バスアクセスインターフェイス、トレースおよびデバッグインターフェイス、CPU 特性取得インターフェイス、割り込みおよびアラームインターフェイスなど。
2.ヒープメモリ管理コンポーネント (Malloc lib) : ヒープメモリ管理コンポーネントは、アプリケーションがラージページメモリからメモリを割り当てるためのインターフェイスを提供します。これらのインターフェイスを使用すると、大きなメモリチャンクを割り当てる必要がある場合に TLB ページフォールトを減らすことができます。
3.リングバッファ管理コンポーネント (Ring lib) : リングバッファ管理コンポーネントは、アプリケーションおよびその他のコンポーネントにロックフリーのマルチプロデューサーおよびマルチコンシューマー FIFO キュー API を提供します: Ring。Ring は、Linux カーネルの kfifo ロックフリーキューに基づいており、ロックなしでペアに出入りでき、複数のコンシューマー/プロデューサーが同時にキューに出入りすることをサポートします。
4.メモリプール管理コンポーネント (Mem pool lib) : アプリケーションやその他のコンポーネントにメモリプールを割り当てるためのインターフェイスを提供します。メモリプールは、固定サイズの複数のメモリブロックで構成されるメモリコンテナであり、同じメモリブロックを格納するために使用できます。メッセージキャッシュブロックなどのオブジェクトエンティティメモリプールは、メモリプールの名前によって一意に識別されます。リングバッファと一連のコアローカルキャッシュキューで構成されます。各コアは、独自のキャッシュキューからメモリブロックを割り当てます。バッファ内のメモリブロックを適用して補完します。ローカルキュー。
5.ネットワークメッセージキャッシュブロック管理コンポーネント (Mbuf lib) : アプリケーションがメッセージ情報の保存に使用されるキャッシュブロックを作成および解放するためのインターフェイスを提供します。これらの MBUF はメモリプールに保存されます。MBUF には 2 種類があり、1 つは一般情報を格納するためのもの、もう 1 つはメッセージ情報を格納するためのものです。
6.タイマーコンポーネント (Timer lib) : 非同期で定期的に (または 1 回だけ) 実行するためのいくつかのインターフェイスを提供し、LIBC のタイマータイマーと同様に、指定した時刻に非同期で実行される関数を指定できますが、ここではタイマーにはアプリケーションプログラムは、メインループ内で rte_timer_manage を定期的に呼び出してタイマーを実行します。タイマーコンポーネントの時間基準は、EAL 層によって提供される時間インターフェイスから取得されます。

上記の 6 つのコアコンポーネントに加えて、DPDK は次の機能も提供します。

1)イーサネットポーリングモードドライバー (PMD) アーキテクチャ: イーサネットドライバーをカーネルからアプリケーション層に移動し、カーネル状態で非同期割り込みメカニズムの代わりに同期ポーリングメカニズムを使用して、メッセージの送受信の効率を向上させます。
2)メッセージ転送アルゴリズムのサポート: ハッシュライブラリと LPM ライブラリは、メッセージ転送アルゴリズムのサポートを提供します。
3)ネットワークプロトコル定義と関連マクロ定義: TCP、UDP、SCTP、その他のプロトコルヘッダー定義など、FreeBSD IP プロトコルスタックに基づく関連定義。
4)パケット QOS スケジューリングライブラリ: ランダム早期検出、トラフィックシェーピング、完全優先および重み付きランダムサイクル優先スケジューリングなどの関連する QOS 機能をサポートします。
5)カーネルネットワークインターフェイスライブラリ (KNI) : DPDK アプリケーションとカーネルプロトコルスタック間の通信方法を提供します。通常の Linux の TUN/TAP インターフェイスに似ていますが、TUN/TAP インターフェイスよりも効率的です。各物理ネットワークポートは複数の KNI インターフェイスを仮想化できます。

プラットフォーム関連モジュール

その内部モジュールには主に KNI、エネルギー管理、IVSHMEM インターフェイスが含まれています。その中で、KNI モジュールは主に kni.ko モジュールを介してユーザー状態からカーネル状態プロトコルスタックにデータメッセージを渡し、ユーザープロセスが従来のソケットインターフェイスを使用して関連メッセージを処理できるようにします。このプログラムは、パケット受信速度に応じてプロセッサ周波数を動的に調整したり、プロセッサの異なるスリープ状態に入ったりすることができます。さらに、IVSHMEM モジュールは、仮想マシン間または仮想マシン間のゼロコピー共有メモリメカニズムを提供します。プログラムの実行中、IVSHMEM モジュールはコアコンポーネントライブラリ API を呼び出し、複数の HugePage を IVSHMEM デバイスプールにマップし、パラメータを QEMU に渡します。これにより、仮想マシン間のゼロコピーメモリ共有が実現します。

ユーザースペースポーリングモード (PMD)

従来の割り込みモード: 従来の Linux システムでは、ネットワークデバイスがデータフレームを検出すると、DMA (ダイレクトメモリアクセス) を使用してフレームを事前に割り当てられたカーネルバッファに送信し、対応する受信記述子リングを更新します。つまり、データフレームが到着していることを通知するために割り込みが生成されます。Linux システムはそれに応じて応答し、対応する記述子リングを更新し、受信したデータフレームを処理のためにカーネル内のネットワークスタックに渡します。ネットワークスタックが処理された後、対応するデータは対応するソケットにコピーされます。これにより、データがユーザー空間にコピーされ、アプリケーションがそのデータを使用できるようになります。データフレームの受信プロセスを図に示します。

データフレーム受信処理

送信時には、ユーザープログラムがデータの処理を完了すると、システムコールを通じてデータをソケットに書き込み、ユーザー空間からカーネル空間のバッファーにデータをコピーし、処理のためにネットワークスタックに渡します。データをカプセル化し、ネットワークカードデバイスのドライバーを呼び出すと、ネットワークカードデバイスのドライバーは送信記述子リングを更新し、送信するデータフレームがあることをネットワークカードデバイスに通知します。ネットワークカードデバイスは、データフレームをカーネル内のバッファから独自のバッファにコピーし、ネットワークリンクに送信します。リンクに送信された後、ネットワークカードデバイスは割り込みを通じて送信の成功を通知し、その後、カーネルは対応するフレームのバッファを解放します。

データは次の図のように送信されます。

データフレームの送信処理

Linux システムは割り込みによってデータパケットが来ていることを CPU に通知するため、ネットワークのトラフィックがますます大きくなると、Linux システムは割り込みに対処するためにますます多くの時間を浪費することになります。、Linux システムは割り込みによって圧倒され、多くの CPU リソースを浪費する可能性があります。

DPDK ユーザー空間用のポーリングモードドライバー: ユーザー空間ドライバーを使用すると、アプリケーションは Linux カーネルを経由せずにネットワークデバイスカードにアクセスできます。ネットワークカードデバイスは、DMA を介して事前に割り当てられたバッファにデータパケットを転送できます。このバッファはユーザー空間にあります。アプリケーションはデータパケットを読み取り、中断のない継続的なポーリングを通じて元のアドレスで直接処理できます。また、カーネルからアプリケーション層にパケットをコピーするプロセスも節約されます。

したがって、Linux システムの従来の割り込み方式と比較して、インテル DPDK は割り込み処理、コンテキスト切り替え、システムコール、データレプリケーションによるパフォーマンスの消費を回避し、データパケットの処理パフォーマンスを大幅に向上させます。同時に、インテル DPDK はユーザー空間でドライバーを開発できるため、カーネルでの従来のドライバー開発と比較して、安全係数が大幅に削減されます。カーネル層の権限は比較的高いため、操作は比較的危険であり、小さなコードのバグがシステムのクラッシュを引き起こす可能性があるため、慎重な開発と広範なテストが必要です。逆に、アプリケーション層では安全であり、アプリケーション層でコードをデバッグする方がはるかに便利です。

ポーリングモードドライバモジュール

PMD関連APIは、ポーリングモードでのネットワークカードメッセージの送受信を実現することで、従来のメッセージ処理方式における割り込みモードによる応答遅延を回避し、ネットワークカード送受信のパフォーマンスを大幅に向上させます。さらに、このモジュールは、Intel ネットワークカードのみのサポートから、Cisco、Broadcom、Mellanox、Chelsio などの業界エコシステム全体のサポートに至るまで、物理ネットワークインターフェイスと仮想化ネットワークインターフェイスの両方もサポートします。また、KVM、VMWARE に基づく仮想化ネットワークインターフェイスもサポートします。、XENなどに対応しています。

DPDK は、ACL、QoS、トラフィック分類、ロードバランシングなどのデータプレーン転送アプリケーションを抽象化するための多数の API も定義します。さらに、イーサネットインターフェイスに加えて、DPDK は暗号化と復号化のためのソフトウェアおよびハードウェアアクセラレーションインターフェイス (拡張機能) も定義しています。

ラージページテクノロジー

プロセッサのメモリ管理は、物理メモリと仮想メモリという 2 つの概念で構成されます。Linux オペレーティングシステムでは、物理メモリ全体がフレームによって管理され、仮想メモリはページによって管理されます。

メモリ管理ユニット (MMU) は、仮想メモリアドレスから物理メモリアドレスへの変換を完了します。メモリ管理ユニットがアドレス変換に必要とする情報は、ページテーブルと呼ばれるデータ構造に格納されており、ページテーブルの検索は非常に時間のかかる操作です。Intelプロセッサでは、ページテーブルの検索処理を軽減するために、TLB(Translation Lookaside Buffer)と呼ばれる、仮想アドレスと物理アドレスのマッピング関係を格納した検索結果を保存するキャッシュを実装しています。すべての仮想アドレスが物理アドレスに変換される前に、プロセッサはまず TLB 内に有効なマッピング関係があるかどうかを確認します。有効なマッピングが見つからない場合、つまり TLS ミスの場合、プロセッサはページテーブルを検索します。ページテーブルの検索処理はパフォーマンスに大きな影響を与えるため、TLBミスの発生を最小限に抑える必要があります。x86 プロセッサハードウェアのデフォルト構成では、ページサイズは 4K ですが、2M または 1G ページテーブルなど、より大きなページテーブルサイズもサポートできます。ラージページテーブル機能を使用すると、TLB エントリがより大きなメモリ領域を指すようになり、TLB ミスの発生を大幅に減らすことができます。初期の Linux では、x86 ハードウェアが提供するラージページテーブル機能が使用されていませんでした。Linux カーネルのバージョン 2.6.33 以降でのみ、アプリケーションソフトウェアでラージページテーブル機能が使用できるようになります。詳細については、Linux ラージページテーブルファイルを参照してください。システム (hugetlbfs ) の特性。

DPDK はヒュージページテクノロジを使用し、すべてのメモリが HugePage から割り当てられ、メモリプール (mempool) の管理を実現し、各データパケットに同じサイズの mbuf を事前に割り当てます。

DPDKにおけるメモリ管理は図のとおりで、下段が2MBのラージページで構成される連続物理メモリ、その上がメモリセグメント、その上がメモリ領域という基本単位になります。オブジェクトはメモリ領域に割り当てられます。メモリ領域には、リングキュー、メモリプール、LPM ルーティングテーブル、および高パフォーマンスのためのその他の主要な構造が含まれます。

ポーリング手法

従来のネットワークカードのメッセージ受信/送信プロセスでは、ネットワークカードハードウェアは、ネットワークメッセージの受信後、またはネットワークメッセージの送信後に CPU に割り込みを送信して、処理すべきネットワークメッセージがあることをアプリケーションソフトウェアに通知する必要がありました。x86 プロセッサでは、割り込み処理では、プロセッサのステータスレジスタをスタックに保存し、割り込みサービスルーチンを実行し、最後に保存されたステータスレジスタ情報をスタックから復元する必要があります。プロセス全体には少なくとも 300 プロセッサクロックサイクルが必要です。高性能ネットワーク処理アプリケーションの場合、頻繁な割り込み処理のオーバーヘッドにより、ネットワークアプリケーションのパフォーマンスが大幅に低下します。

割り込み処理のオーバーヘッドを軽減するために、DPDK はポーリングテクノロジを使用してネットワークパケットを処理します。ネットワークカードはメッセージを受信すると、メッセージをプロセッサキャッシュに直接保存するか (DDIO (ダイレクトデータ I/O) テクノロジを使用する場合)、またはメモリに保存し (DDIO テクノロジを使用しない場合)、レポートのテキストのフラグビットを設定します。到着。アプリケーションソフトウェアは、メッセージ到着のフラグビットを定期的にポーリングして、処理すべき新しいメッセージがあるかどうかを検出します。処理全体を通じて処理プロセスが中断されることがないため、アプリケーションプログラムのネットワークパケット処理能力が大幅に向上します。

CPUアフィニティテクノロジー

最新のオペレーティングシステムは、タイムシェアリング呼び出しに基づいてタスクスケジューリングを実装しており、複数のプロセスまたはスレッドがマルチコアプロセッサの特定のコアで継続的かつ交互に実行されます。各スイッチングプロセスでは、プロセッサのステータスレジスタをスタックに保存し、現在のプロセスのステータス情報を復元する必要があります。これは実際にはシステムの一種の処理オーバーヘッドです。スレッドを 1 つのコアで実行するように修正すると、切り替えによって発生する余分なオーバーヘッドを排除できます。さらに、プロセスまたはスレッドがマルチコアプロセッサの他のコアに移行されて動作する場合、プロセッサキャッシュ内のデータもクリアする必要があるため、プロセッサキャッシュの使用率が低下します。

CPU アフィニティテクノロジは、特定のプロセスまたはスレッドを、他のコアに移行して実行することなく、1 つ以上の特定のコアにバインドして実行することで、専用プログラムのパフォーマンスを保証します。

DPDK は Linux pthread ライブラリを使用して、対応するスレッドをシステム内の CPU アフィニティにバインドし、対応するスレッドは関連するデータ処理に可能な限り独立したリソースを使用します。

マルチコアプロセッサマシンでは、各 CPU コアに独自のキャッシュがあり、スレッドが使用する情報を保存します。スレッドが CPU コアにバインドされていない場合、Linux システムによってスレッドが他の CPU にスケジュールされる可能性があり、この場合、CPU のキャッシュヒット率が低下します。CPU アフィニティテクノロジを使用すると、スレッドが特定の CPU にバインドされると、スレッドは常に指定された CPU 上で実行され、オペレーティングシステムはスレッドを他の CPU にスケジュールしなくなり、スケジューリングによるパフォーマンスの消費が節約され、それによってプログラムの効率が向上します。実行。

マルチコアポーリングモード: マルチコアポーリングモードには、IO 排他モードとパイプラインモードの 2 つがあります。IO排他とは、データパケットの受信、処理、送信の処理を各コアが独立して完了することを意味し、各コアが独立しているため、1つのコアに障害が発生してもデータの送受信に影響を与えないという利点があります。他のコアの。パイプラインタイプでは、マルチコアの連携を使用してデータパケットを処理し、データパケットの受信、処理、送信が異なるコアによって完了します。パイプラインはストリーム指向のデータ処理に適しています。その利点は、データパケットを受信した順に処理できることです。欠点は、特定の環境 (受信など) に関与するコアがブロックされると、送受信が中断される原因となります。

IO 排他的マルチコアポーリングモードでは、各ネットワークカードは処理のために 1 つの論理コアにのみ割り当てられます。各論理コアは、引き継ぐネットワークカードに送信キューと受信キューを割り当て、データパケットの受信、処理、送信のプロセスを独立して完了し、コアは互いに独立しています。システムデータパケットの処理は複数の論理コアによって同時に実行され、各ネットワークカードの送受信パケットキューは 1 つの論理コアによってのみ提供されます。データパケットがネットワークカードのハードウェアバッファ領域に入ると、ユーザー空間によって提供されるネットワークカードドライバーは、ネットワークカードがポーリングを通じてデータパケットを受信したことを認識し、ハードウェアバッファからデータパケットを取り出し、保存します。論理コアが提供するパケット受信キューにデータパケットが格納されると、論理コアはパケット受信キューのデータパケットを取り出して処理し、処理後、データパケットは論理コアが提供する送信キューに格納され、ネットワークカードドライバーによって取り出され、ネットワークカードに送信され、最終的にネットワークに送信されます。

AWCloud での DPDK のアプリケーション

DPDK (Data Plane Development Kit) データプレーン開発ツールセットは、インテルアーキテクチャ (IA) プロセッサアーキテクチャの下でユーザー空間で効率的にデータパケットを処理するためのライブラリ関数とドライバーサポートを提供します。代わりに、ネットワークアプリケーションにおけるパケットの高性能処理に重点を置いています。DPDK アプリケーションはユーザー空間で実行され、Linux カーネルプロトコルスタックによるデータパケットの処理プロセスをバイパスして、独自に提供されるデータプレーンライブラリを使用してデータパケットを送受信します。データ処理を高速化するために、ユーザーは独自のアプリケーション要件に合わせてユーザー空間のプロトコルスタックをカスタマイズできます。従来のカーネルベースのネットワークデータ処理と比較して、DPDK はカーネル層からユーザー層までのネットワークデータフローに大きな進歩をもたらしました。

DPDK 機能は、クラウドホストと物理ホストがネットワークパケットを処理する速度を高速化するために使用されます。ラージページメモリや CPU アフィニティなどの一連のテクノロジーにより、ネットワークデータパケットを処理するためのシステムの煩雑なプロセスをバイパスし、ネットワークパフォーマンスを向上させます。

次の図に示すように、クラウドプラットフォームは DPDK テクノロジーを使用してネットワークパフォーマンスの最適化を実現します。

メモリプールとロックフリーのリングキャッシュ管理

さらに、インテル DPDK は、ロックフリーキューなどのライブラリと API をロックフリーになるように最適化し、マルチスレッドプログラムでのデッドロックを防ぐことができます。次に、バッファなどのデータ構造に対してキャッシュアライメントが実行されます。キャッシュのアライメントがない場合は、メモリアクセス中にもう一度メモリとキャッシュの読み書きを行うことができます。

メモリプールのキャッシュ領域の適用と解放は、プロデューサー/コンシューマモードのロックフリーキャッシュキューによって管理されます。これにより、キュー内のロックのオーバーヘッドが回避され、キャッシュ領域使用中のバッファ適用解放の効率が向上します。

ロックフリーリングキューの作成プロセス

ロックフリー循環キュー消費プロセス

図に示すように、プロデューサーがコンテンツをキューに格納する方向は、コンシューマーがキューからコンテンツをフェッチする方向と同じで、どちらも時計回りです。バッファ領域がメモリプールからメモリブロックに適用されるか、アプリケーションプログラムがメモリブロックを解放すると、バッファ領域内のロックフリー循環キューのプロデューサポインタが時計回りに移動し、メモリブロックのアドレス情報をバッファ領域に格納します。バッファキュープロセスを生成するためのキュー。アプリケーションがバッファからメモリブロックを申請する必要がある場合、バッファのロックフリー循環キューのコンシューマポインタは、キューのメモリブロックアドレスを時計回りに取り出してアプリケーションに割り当てます。このプロセスが消費です。バッファキューの処理。

n 個のオブジェクトを生成するプロセス: まず、プロデューサーヘッドポインターが時計回りに n 位置移動して新しいヘッドポインターを取得し、次にプロデューサーテールポインターが指す領域から n 個のオブジェクトを 1 つずつ格納し、最後にプロデューサーテールポインターが時計回りに移動します。 n 位置は新しいプロデューサーテールポインタを取得します

n 個のオブジェクトを消費するプロセス: まず、コンシューマヘッドポインタが時計回りに n 位置移動して新しいコンシューマヘッドポインタを取得し、次にコンシューマテールポインタから n 個のオブジェクトを 1 つずつ読み取り、最後にコンシューマテールポインタが時計回りに n 位置を移動します。新しいコンシューマテールポインタ。

ネットワークストレージの最適化

4. 3DPDKの躍進

従来の Linux カーネルネットワークデータフロー:

硬件中断--->取包分发至内核线程--->软件中断--->内核线程在协议栈中处理包--->处理完毕通知用户层
用户层收包-->网络层--->逻辑层--->业务层

dpdk ネットワークデータフロー:

硬件中断--->放弃中断流程
用户层通过设备映射取包--->进入用户层协议栈--->逻辑层--->业务层

4.4 KNI コンポーネント

KNI は、カーネルプロトコルスタックにデータを再入力するために DPDK プラットフォームによって提供されるコンポーネントであり、その目的は、従来のカーネルプロトコルスタックによって実装されていたより安定したプロトコル処理機能を最大限に活用することです。DPDK プラットフォームによるデータパケットの処理は、カーネルプロトコルスタックをバイパスし、処理のためにユーザー空間に直接渡されます。ただし、ユーザー空間には完全なプロトコル処理スタックがありません。開発者が完全で独立したプロトコルを実装できる場合は、ユーザー空間にプロトコルスタックを実装すると、開発作業は非常に複雑になります。はい、DPDK プラットフォームは KNI コンポーネントを提供します。開発者はユーザー空間にいくつかの特殊なプロトコル処理機能を実装し、一般的なプロトコルを従来のカーネルに引き渡すことができます。 KNI リエントリーカーネルプロトコルスタック関数を通じて処理するためのプロトコルスタック。

KNI 通信メカニズム

KNI コンポーネントは、KNI 仮想インターフェイスデバイスを作成し、仮想インターフェイスを介してデータパケットを渡すことにより、ユーザー空間とカーネルプロトコルスタック間の通信を実現します。ネットワークカードがデータパケットを受信すると、アプリケーションプログラムはユーザー空間ドライバーを通じてデータパケットをユーザー空間に取得し、KNI コンポーネントは必要なデータパケットを KNI 仮想インターフェイスに送信し、KNI 仮想インターフェイスは処理のためにカーネルプロトコルスタックに渡され、処理後、応答がある場合、メッセージは KNI 仮想インターフェイスに渡されて、アプリケーションプログラムに返されます。このうち、カーネルプロトコルスタックに送信されるデータパケットとカーネルプロトコルスタックから受信されるデータパケットは、アプリケーションプログラムをブロックすることなく、カーネルプロトコルスタックにデータパケットを送信したり、カーネルプロトコルスタックからデータパケットを受信したりするアプリケーションプログラムをブロックすることなく、それぞれ 2 つの異なるロジックコアによって処理されます。カーネルプロトコルスタックプロセス。

KNI インターフェイスは、実際には 4 つのキュー、つまり受信キュー (rx_q)、送信キュー (tx_q)、割り当てられたメモリブロックキュー (alloc_q)、および解放されるメモリブロックキュー (free_q) を定義する仮想デバイスです。受信キューは、ユーザー空間プログラムによって KNI 仮想デバイスに送信されたメッセージを格納するために使用され、送信キューは、カーネルプロトコルスタックによって KNI 仮想デバイスに送信されたメッセージを格納するために使用されます。割り当てメモリブロックキューは、申請されたメモリブロックをメモリ上に格納し、カーネルプロトコルスタックがメッセージを送信する際の取り出しに使用される。解放されるメモリブロックキューは、KNI 仮想デバイスがユーザー空間プログラムからメッセージを受信した後に使用されなくなるメモリブロックを記録し、キュー内のメモリブロックをメモリに解放するために使用されます。ユーザー空間プログラムは、ネットワークカードからメッセージを受信すると、そのメッセージを KNI 仮想デバイスに送信し、KNI 仮想デバイスがユーザー空間プログラムからメッセージを受信すると、プロトコル分析のためにそのメッセージをカーネルプロトコルスタックに渡します。メッセージを送信するとき、元のデータは最初にカーネルプロトコルスタックによってカプセル化され、次にメッセージが KNI 仮想デバイスに送信されます。KNI 仮想デバイスはメッセージを受信した後、ユーザー空間プログラムにメッセージを送信します。

4.5 DKDP コアの最適化

DPDKのUIOドライバはハードウェアによる割り込みをシールドし、ユーザーモードでアクティブポーリング方式を採用しており、このモードをPMD(Poll Mode Driver)と呼びます。

UIO はカーネルをバイパスし、ハード割り込みをアクティブにローテーションして削除するため、DPDK はユーザーモードでパケットの送受信を処理できます。ゼロコピーとシステムコールがないという利点があり、同期処理によりコンテキストスイッチングによって引き起こされるキャッシュミスが減少します。

PMD 上で実行されている CORE は、CPU が 100% の状態になります。

ネットワークがアイドル状態の場合、CPU は長時間アイドル状態になり、エネルギー消費の問題が発生します。したがって、DPDK は割り込み DPDK モードを起動しました。

DPDKを中断：

DPDK の高性能コード実装

1. **HugePage を使用して TLB ミスを削減する: **Linux はデフォルトで 4KB をページとして使用します。ページが小さいほどメモリが大きくなり、ページテーブルのオーバーヘッドが大きくなり、ページのメモリ使用量も大きくなります。テーブル。CPU には高価なTLB (Translation Lookaside Buffer) が搭載されているため、一般に数百から数千のページテーブルエントリしか保存できません。プロセスが 64G メモリを使用する必要がある場合、64G/4KB=16000000 (1600 万) ページとなり、各ページはページテーブルエントリで 16000000 * 4B=62MB を占有します。HugePage を使用して 2MB をページとして使用する場合、必要なのは 64G/2MB=2000 だけであり、その量は同レベルではありません。DPDK は、x86-64 で 2MB および 1GB のページサイズをサポートする HugePage を使用します。これにより、ページテーブルエントリのサイズが幾何学的に縮小され、それによって TLB ミスが削減されます。また、メモリプール (Mempool)、MBuf、ロックレスリング (Ring)、ビットマップなどの基本的なライブラリも提供します。私たちの実践によれば、データプレーン (データプレーン) で頻繁にメモリの割り当てと解放を行うには、rte_malloc を直接使用する代わりにメモリプールを使用する必要があります。DPDK のメモリ割り当ての実装は非常に単純ですが、ptmalloc ほど優れていません。

2. **SNA（Shared-nothing Architecture）** ソフトウェアアーキテクチャの分散化により、グローバルな共有を回避しようとし、グローバルな競争をもたらし、水平方向の拡張能力を失います。NUMA システムでは、メモリはノード間でリモートで使用されません。

3. **SIMD (単一命令複数データ)** 初期の mmx/sse から最新の avx2 まで、SIMD の機能は向上しています。DPDK はバッチを使用して複数のパッケージを同時に処理し、ベクトルプログラミングを使用してすべてのパッケージを 1 サイクルで処理します。たとえば、memcpy は速度向上のために SIMD を使用します。SIMD はゲームのバックグラウンドでより一般的ですが、他の企業でも同様のバッチ処理シナリオがあり、パフォーマンスを向上させる必要がある場合、それが満足できるかどうかを確認することもできます。

4. **遅い API は使用しないでください:** ここでは、gettimeofday などの遅い API を再定義する必要があります。ただし、 64 ビットではvDSOを通じてカーネルモードに入る必要はなくなりました。これは単なるメモリです。アクセスは 1 秒で数千万レベルに達します。ただし、10GE 未満では、1 秒あたりの処理能力が数千万に達することを忘れないでください。したがって、gettimeofday でさえ遅い API です。DPDK は、HPET または TSC に基づいて実装される rte_get_tsc_cycles インターフェイスなどの Cycles インターフェイスを提供します。

5、DPDKビデオチュートリアル

【DPDK高性能ストレージ】 dpdkはtcpipプロトコルスタックから起動し、一緒に起動するLinux環境を準備します

[DPDk 高性能ストレージ] C/C++ 開発は優れた技術的方向性、dpdk ネットワーク開発

[DPDK 高性能ストレージ] dpdk の基本原理により、別の技術的方向性を開くことができます

【DPDK高性能ストレージ】DPDKの過去と現在、cc++プログラマの今後の方向性

【DPDK高性能ストレージ】dpdkの仮想化、vhostとvirtioの話、そしてqemuの実現原理

【DPDK高性能ストレージ】nff-goとdpdkの話、golangのc呼び出しのプロセス解析

[DPDK高性能ストレージ] dpdkの5つの誤解、コードを使用して解決、dpdk手書きプロトコルスタックから始める

【DPDK高性能ストレージ】dpdkspdk開発に関する10の技術的課題

[DPDK 高性能ストレージ] fio の iops テスト、fio 用の spdk エンジンを手書き (独自の Linux 環境を持参)

【DPDK高性能ストレージ】vppソースコードプロセス解析、ダイナミックライブラリローディング、プラグイン、ノード、フィーチャープロセス

[DPDK 高性能ストレージ] SPDK はどのようにして NVMe の高性能で詳細な動作原理を実現するのか

[DPDK 高性能ストレージ] ストレージフレームワーク spdk がテクノロジースタックのストレージの扉を開きます

【DPDK高性能ストレージ】6つの質問を理解して、dpdk/spdkの高性能開発への道を歩み始めましょう

6. 手書きの TCP/IP ユーザーモードプロトコルスタック (純粋な C 言語)

(1) DPDKの基礎知識

1. dpdk環境構築とマルチキューネットワークカード
2. dpdkネットワークカードバインディングとarp
3. dpdk送信処理の実現
4. dpdk送信処理のデバッグ
5. dpdk-arpの実装
6. ARP デバッグプロセス
7. dpdk-icmpの実装
8. Dpdk-icmp プロセスのデバッグとチェックサムの実装
9. ARPテーブルの実装

(2) プロトコルスタックのudp/tcpの実装

1.Arpリクエストの実装
2. ARP デバッグプロセス
3. プロトコルスタックアーキテクチャ設計の最適化
4. udp実装のためのudpシステムAPIの設計
5. udpで実装されたsbufとrbufのリングキュー
6. udpにより実現される送信処理と同時実行性の分離
7. udp実装のアーキテクチャ設計とデバッグ
8. TCP スリーウェイハンドシェイクのための dpdk TCP プロセスアーキテクチャの設計
9. tcp スリーウェイハンドシェイクによる dpdk tcp11 状態の実現
10. TCP スリーウェイハンドシェイクの Dpdk コードデバッグ

(3) プロトコルスタックのtcpの実装

1. TCP データ送信用の ack および seqnum 確認コードとスライディングウィンドウの実装
2. TCP データ送信とスライディングウィンドウの ack および seqnum コードの実装
3. TCPプロトコルAPI実装のバインドとリッスンの実現
4. TCPプロトコルAPI実装でのacceptの実装
5. TCPプロトコルAPI実装のsendとrecvの実装
6. TCPプロトコルAPI実装でのcloseの実装
7. セグメンテーション違反と TCP プロトコルスタックデバッグのロジックフロー
8. TCP プロトコルスタックのデバッグでのリングバッファメモリエラー。
9. dpdk kni と kni 起動の原理
10. ネットワークプロトコル配布プロセスを再構築する

(4) プロトコルスタックの構成要素機能

1. kni パケットキャプチャのデバッグ tcpdump
2. dpdk kni mempool エラーとメモリリーク
3. エントロピーベースの DDO 検出の数学理論
4. dpdk ddos エントロピー計算コードの実装
5. dpdkddosattach 検出精度のデバッグ
6. DDOS攻撃テストツール hping3
7. dpdkカッコーハッシュの原理と応用

(5) TCPプロトコルスタックの同時実装

1. TCP同時接続の設計
2. tcp 同時 epoll の実装
3. TCP 同時プロトコルスタックと epoll のコールバックと同時実行テスト
4. bpf および bpftrace システム、ネットワークマウントの実装
5. bpf および bpftrace アプリケーション ntyco のマウント監視

(6) DPDK ネットワーク基本コンポーネント

1. mempoolとmbufのソースコード解析と解説
2. dpdk-ringbufferのソースコード解析
3. dpdk-igb_uio ソースコード解析
4. dpdk-kni ソースコードの解析
5. rcuと相互排他ロック、スピンロック、リードライトロックの実現

問題を解く

1. 実際のプロジェクトに応募せずにオンライン書籍を一生懸命勉強する
2. 履歴書に書くのに適したネットワークプロジェクトがない
3. C の基礎があり、純粋に興味がある

3000 行の手書きコードで、ネットワーク通信のコア技術を習得できます。

7. DPDK市場の発展

DPDK のアプリケーションのほとんどは、もともと通信分野で使用されていました。CSP は運用コストを削減し、新しいサービスの展開を加速するためにネットワーク仮想化を採用し、ルーター、ファイアウォール、無線アクセスネットワーク (RAN)、進化したパケットコア (EPC) など、高スループットや低遅延を必要とするユースケースを仮想化します。。仮想化プラットフォームのベンダー (この場合、VNF とアプリケーション) は、CSP のパフォーマンス目標を達成するために自社の製品で DPDK を活用しています。CSP がビデオキャッシュ、監視、拡張現実 (AR)、運転支援、小売および産業用 IoT などの新しいエッジホストアプリケーションを模索する中、DPDK は依然として積極的なパフォーマンス目標を達成するための重要なテクノロジです。

DPDK が最初に通信アプリケーションで使用されたパケット処理機能のパフォーマンス要件と同様に、DPDK は企業やクラウドでも使用されることが増えています。たとえば、VMware は 2018 年に、NSX-T データセンターのソフトウェアデファインドインフラストラクチャに DPDK ベースのエッジプロビジョニングを導入しました。このリリースの NSX-T は、可変パケットサイズで高いパケットスループットを必要とするアプリケーションと、最大 100 Gbps North/South トラフィックの高速 NIC をサポートするサーバーに対応します。通常、North-South フローは、トラフィック全体の 20% 未満であっても、パケットサイズとパケット処理要件が異なります。この使用例では、小さいパケット (64 バイト) で DPDK を使用することにより、Intel と VMware による分析でパフォーマンスが 5 倍向上したことが示されています。

一方、いくつかの企業は金融アプリケーションに DPDK を使用しており、低遅延が大きな競争上の優位性をもたらします。たとえば、高頻度取引 (HFT) では、遅延はトレーダーの取引効率、アルゴリズム戦略、競合他社を上回るパフォーマンスを発揮する能力に直接影響を与える可能性があります。InformationWeek は、大手証券会社の場合、1 ミリ秒は年間 1 億ドルの価値があると推定しています。DPDK は、この市場のソリューションプロバイダーが開発に依存する重要なテクノロジーです。

最後に次のように書きます。

Dpdk は、インターネット上でますます人気が高まっている基盤テクノロジーとして、ますます多くの優れたインターネット企業に歓迎され、使用されています。しかし、多くのプログラマにとっては、見たり聞いたりしただけで、詳しく調べたり使用したりしたことはありません。dpdk にも興味がある場合、または dpdk エンジニアになる予定の友人がいる場合は、[ dpdk/ネットワークプロトコルスタック/vpp/OvS/DDos/SDN/NFV/仮想化/ハイパフォーマンスエキスパートロード]を参照してください。システムコース。

著作権に関する声明: この記事は、Zhihu ブロガー「Linux カーネルで遊ぶ」によって書かれたオリジナルの記事です。CC 4.0 BY-SA 著作権契約に従っています。転載する場合は、元のソースのリンクとこの声明を添付してください。
元のリンク: https://zhuanlan.zhihu.com/p/638255695