いくつかの古典的な Linux パケット収集エンジン-Linuxの運用と保守-php.cn

いくつかの古典的な Linux パケット収集エンジン

Linux中文社区

リリース： 2023-08-04 16:07:06

転載

1881 人が閲覧しました

この記事では、4 つの古典的な Linux パケット収集エンジンをリストします。他にも問題ないと思われるエンジンがある場合は、メッセージを残してください。これら 4 つは次のとおりです:

#libpcap/libpcap-mmap
PF_RING
DPDK

libpcap

libpcap のパケットキャプチャメカニズムは、バイパス処理を追加することで、システム独自のネットワークプロトコルスタックの処理送受信されたデータパケットは、Linux カーネルを通じてフィルタリングおよびバッファリングされ、最終的に上位層アプリケーションに直接渡されます。

データパケットはネットワークカードデバイスに到着します。
#ネットワークカードデバイスは、設定に従って DMA 操作を実行します。 (
「最初のコピー」 : ネットワークカードレジスタ -> カーネルによってネットワークカードに割り当てられたバッファリングバッファ)
「2 番目のコピー」 : カーネルネットワークカードバッファリングバッファ -> カーネル固有のデータ構造 skbuff)

「3 番目のコピー」 )。 BPF は、サービスを必要とする各パケットキャプチャプログラムに 1 つのフィルタと 2 つのバッファを関連付けます。 BPF はバッファを割り当て、そのサイズは通常 4KB です。ストアバッファはアダプタからデータを受信するために使用され、ホールドバッファはパケットをアプリケーションにコピーするために使用されます。
「4 番目のコピー」 )

libpcap-mmap は古い libpcap 実装を改良したもので、新しいバージョンの libpcap は基本的に packet_mmap メカニズムを使用します。 PACKET_MMAP は mmap を使用して 1 つのメモリコピー (

「4 番目のコピーがなくなりました」 ) を削減し、これにより頻繁なシステムコールが削減され、メッセージキャプチャの効率が大幅に向上します。

PF_RING

libpcap には 4 つのメモリコピーがあることが以前に確認されました。 libpcap_mmap には 3 つのメモリコピーがあります。 PF_RING が提案する中心的なソリューションは、送信中のメッセージのコピーの数を減らすことです。

libpcap_mmap と比較すると、pfring ではユーザー空間メモリを rx_buffer で直接 mmap できることがわかります。これにより、別のコピー ( 「libpcap_mmap の 2 番目のコピー」: rx_buffer->skb)

PF-RING ZC が DNA (ダイレクト NIC アクセス (ダイレクトネットワークカード) を実装) が削減されます。 access) テクノロジーは、ユーザーメモリ空間をドライバーのメモリ空間にマップし、ユーザーアプリケーションがネットワークカードのレジスタおよびデータに直接アクセスできるようにします。

このようにして、カーネル内のデータパケットのキャッシュが回避され、コピーが 1 つ削減されます ( 「libpcap の最初のコピー」 、DMA からカーネルバッファへのコピー)。これは完全にゼロコピーです。

欠点は、一度に 1 つのアプリケーションしか DMA リングを開くことができないことです (今日のネットワークカードは複数の RX/TX キューを持つことができ、1 つのアプリケーションが同時に各キューに存在できることに注意してください)。つまり、ユーザーモードの複数のアプリケーションは、データパケットを分散するために相互に通信する必要があります。

DPDK

pf-ring zc と dpdk はどちらもデータパケットのゼロコピーを実現でき、どちらもカーネルをバイパスしますが、実装原理は若干異なります。 PF リング zc は、zc ドライバー (アプリケーション層でも) を通じてデータパケットを引き継ぎ、dpdk は UIO に基づいて実装されます。

1 UIO mmap はゼロコピーを実装します

UIO (ユーザー空間 I/O) は、ユーザー空間で実行される I/O テクノロジです。一般に、Linux システムのドライバーデバイスはカーネル空間で実行され、ユーザー空間のアプリケーションから呼び出すことができますが、UIO はドライバーのごく一部をカーネル空間で実行し、ドライバーの大部分をユーザー空間で実装します。関数。 Linux が提供する UIO メカニズムを使用すると、カーネルをバイパスでき、すべてのパケット処理作業がユーザー空間で完了します。

2 UIO PMD は割り込みと CPU コンテキストの切り替えを軽減します

DPDK の UIO ドライバーはハードウェア発行の割り込みをブロックし、ユーザーモードでアクティブポーリングを使用します。このモードは PMD と呼ばれます。 (ポーリングモードドライバー)。

DPDK と比較すると、pf-ring (zc なし) は NAPI ポーリングとアプリケーション層ポーリングを使用しますが、pf-ring zc は DPDK に似ており、アプリケーション層ポーリングのみを使用します。

3 HugePages による TLB ミスの削減

MMU (メモリ管理ユニット) がオペレーティングシステムに導入された後、CPU はメモリを読み取るためにメモリに 2 回アクセスする必要があります。データ。 1 回目は、ページテーブルにクエリを実行して論理アドレスを物理アドレスに変換し、その物理アドレスにアクセスしてデータまたは命令を読み取ります。

ページ数やページテーブルが大きすぎることによって引き起こされるクエリ時間が長すぎる問題を軽減するために、アドレス変換バッファとして変換できる TLB (Translation Lookaside Buffer) が導入されました。 TLB はメモリ管理ユニットであり、通常はレジスタに格納され、現在アクセスされる可能性が最も高いページテーブルエントリの小さな部分が格納されます。

TLB の導入後、CPU はまず TLB 内を検索しますが、TLB はレジスタに格納され、ページテーブルエントリのごく一部しか含まれていないため、クエリ速度は非常に高速です。 TLB でのアドレス指定が成功した場合 (TLB ヒット)、RAM 内のページテーブルをクエリする必要はありませんが、TLB でのアドレス指定が失敗した場合 (TLB ミス)、RAM 内のページテーブルをクエリする必要があります。クエリ後、ページはTLB に更新されます。

DPDK は、x86-64 で 2MB および 1GB のページサイズをサポートする HugePages を使用します。これにより、総ページ数とページテーブルのサイズが大幅に削減され、TLB ミスの可能性が大幅に減少し、CPU が向上します。アドレス性能です。

4 その他の最適化

SNA (シェアードナッシングアーキテクチャ)、ソフトウェアアーキテクチャは分散型であり、グローバルな共有を回避し、グローバルな共有を実現しようとします。競争が起こり、水平方向に拡張する能力が失われます。 NUMA システムでは、メモリはノード間でリモートで使用されません。
SIMD (単一命令複数データ)、初期の mmx/sse から最新の avx2 まで、SIMD の機能は増加しています。 DPDK は、複数のパケットを同時にバッチ処理し、ベクトルプログラミングを使用してすべてのパケットを 1 サイクルで処理します。たとえば、memcpy は SIMD を使用して速度を向上させます。
cpu アフィニティ: CPU アフィニティ

XDP

xdp は eXpress データパスを表します。パケットフィルタリング用の ebpf データパケットをユーザーモードに直接送信し、ユーザーモードを高速データ処理プレーンとして使用する dpdk と比較して、xdp はドライバー層にデータ高速プレーンを作成します。データパケットは、ネットワークカードハードウェアによってメモリにデータが転送され、skb が割り当てられる前に処理されます。

XDP はデータパケットに対してカーネルバイパスを実行せず、事前に少しの事前チェックを行うだけであることに注意してください。

DPDK と比較すると、XDP には次の利点があります: