したがって、約 5.12Gb/s (約 320e6 パケット/秒) のデータ レートで 272 バイトのパケットで構成される受信 UDP ストリームがあります。このデータは、FPGA ベースのカスタム ボードによって送信されています。パケット サイズは実行中のデジタル デザインの制限であるため、理論的にはそれを増やして効率化することは可能ですが、多大な作業が必要になります。受信側で、これらのパケットはネットワーク スレッドによって読み取られて解釈され、バッファリング スレッドと共有される循環バッファに配置されます。バッファリング スレッドは、このデータを GPU にコピーして処理します。
受信側の上記のセットアップは、単純な呼び出しを使用して 4096 KB パケット (別の設計で使用) の 5.12Gb/s に対処できますがrecv、現在のパケット サイズでは、パケット フローについていくのにも苦労しています。コンテキストの切り替えと、カーネル空間からユーザー空間への小さなデータセグメントのコピーに多くの時間が「無駄」になっています。を使用する簡単なテスト実装を行いましたがrecvmmsg、あまり改善されませんでした。平均して、着信パケットの約 40% を処理できます。
それで、アプリケーション (mmap スタイル) 用にカーネルの UDP データ バッファのハンドルを取得できるかどうか、またはカーネルからユーザー空間への何らかのゼロ コピーを使用できるかどうか疑問に思っていました。または、このオーバーヘッドを削減し、必要な処理を実行できる他の方法を知っていますか?
これは、C コードを使用して Linux マシン (カーネル 3.2.0-40) で実行されています。