Receive Side Scaling (RSS)、Receive Packet Steering (RPS)、および同様のテクノロジについて多くのことを読んだことがありますが、プログラムでそれらを実際にどのように使用できるかについて途方に暮れています。スレッド/プロセス。
PF_RING については知っていますが、Linux カーネル自体に何らかの基本的なサポートがあるに違いないと思います。結局のところ、たとえば Interl は、自社の Web サイトで自社の RSS テクノロジを自慢しており、Linux のサポートを主張しています。また、RPS は PF_RING の範囲外です。私が PF_RING の使用に消極的であるもう 1 つの理由は、ネットワーク ドライバーにパッチが適用されており、パッチが適用されたドライバーの一部が古くなっているように見えることです。
私はこのトピックを広範囲にグーグル検索しましたが、私が見つけた最良の方法は、プログラムでそれらを使用する方法ではなく、RSS または RPS のサポートを有効にすることです。
カーネル 3.19 では、SO_INCOMING_CPU ソケット オプションが導入されました。これにより、プロセスはパケットが最初に配信された CPU を特定できます。
RPS/RFS の代替手段は、マルチ キューのハードウェア サポートを使用することです。
次に、何百万ものソケットのセットをワーカー スレッドに分割し、それぞれが epoll() を使用して独自のソケット プールでイベントを管理します。
理想的には、RX/TX キュー/CPU ごとに 1 つのスレッドが必要ですが、accept() または connect() の後で、どのキュー/CPU でソケットが管理されているかを知る方法がありません。
通常、RX キューごとに 1 つの CPU を使用するため (IRQ smp_affinity が適切に設定されている)、ソケット構造でどの CPU が最後のパケットを配信したかを覚えておくだけで問題を解決できます。
accept()、connect()、さらにはファイル記述子がプロセスを通過した後、アプリケーションは以下を使用できます。
int cpu; socklen_t len = sizeof(cpu);
getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
そして、この情報を使用して、最適なパフォーマンスのためにソケットを適切なサイロに配置します。これは、IPI (RPS/RFS) を送信する必要なく、すべてのネットワーク スタックが適切な CPU で実行される必要があるためです。