マルチコアネットワークパケットステアリング

マルチコアアーキテクチャの送受信トラフィックのネットワークパケットステアリングは、現代のネットワークコンピューティング環境、特に高帯域幅と高負荷によって単一コアのキューが簡単に混雑するデータセンターで必要となります。[ 1 ]

受信パケットがコアのキューに到達するまでに通過する必要があるパスを示すシンプルなグラフ

このため、ハードウェアとソフトウェアの両方において、多くの技術が、プロセッサのコア全体に着信パケットの負荷を分散するために活用されています。 トラフィックの受信側で、この記事で紹介する最も注目すべき技術は、RSS、aRFS、RPS、およびRFSです。 送信については、XPSに焦点を当てます。[ 2 ] [ 3 ] 横の図に示すように、ネットワークインターフェイスカード（NIC）に入ってくるパケットは処理され、コアによって管理される受信キューにロードされます（コアは通常、カーネル空間内にリングバッファとして実装されています）。 主な目的は、 CPU内で利用可能なすべてのコアを活用して着信パケットを処理し、レイテンシやスループットなどのパフォーマンスを向上させることです。[ 4 ] [ 5 ] [ 6 ]

ハードウェア技術

RSSやaRFSなどのハードウェアアクセラレーション技術は、プロセッサの複数のコアのキュー間で受信パケットをルーティングおよび負荷分散するために使用されます。 [ 1 ] これらのハードウェアサポート方式は、ソフトウェアベースの方式と比較して、非常に低いレイテンシを実現し、CPU負荷を軽減します。ただし、ネットワークインターフェースコントローラ（例えば、SmartNICのようなより高度なカードでは通常利用可能）に統合された専用のハードウェアが必要です。[ 7 ] [ 8 ]

RSS

受信側スケーリングアーキテクチャの簡単な図

受信側スケーリング（RSS）は、ハードウェアでサポートされる技術であり、ハッシュ関数によって提供される結果の最終ビットでインデックス付けされた間接テーブルを活用し、パケットのヘッダーフィールドを入力として受け取ります。ハッシュ関数の入力は通常カスタマイズ可能であり、使用されるヘッダーフィールドはユースケースや実装によって異なります。ハッシュのキーとして選択されるヘッダーフィールドの代表的な例としては、レイヤー3のIP送信元および宛先アドレス、プロトコル、レイヤー4の送信元および宛先ポートなどがあります。これにより、同じフローに対応するパケットは、元の順序を失うことなく、同じ受信キューに送られ、順序外配信が発生することはありません。さらに、ハッシュ関数の特性により、すべての受信フローは利用可能なすべてのコア間で負荷分散されます。 [ 5 ] 間接テーブルによって導入されるもう1つの重要な機能は、ハッシュ関数を変更することなく、テーブルエントリを更新するだけで、フローとコアのマッピングを変更できることです。[ 9 ] [ 10 ] [ 4 ] [ 11 ]

aRFS

加速受信フローステアリングアーキテクチャの簡単な図

アクセラレーテッド・レシーブ・フロー・ステアリング（aRFS）は、キャッシュの局所性を利用して着信パケットフローを特定のコアにルーティングすることでパフォーマンスを向上させるという発想から生まれた、ハードウェアでサポートされるもう1つの技術です。完全に独立したハードウェア実装であるRSSとは異なり、aRFSは適切に機能するためにソフトウェア（カーネル）とのインターフェースを必要とします。[ 12 ] RSSは、着信トラフィックをコア間で単純に負荷分散します。しかし、受信パケットを必要とするアプリケーションがコアjで実行されているときに、パケットフローが（ハッシュ関数の結果として）コアiに向けられた場合、 i=jを強制するだけで多くのキャッシュミスを回避でき、パケットは必要な場所で正確に受信され、消費されます。[ 8 ]これを実現するために、aRFSはハッシュ関数の結果から直接パケットを転送するのではなく、設定可能なルーティングテーブル（例えば、スケジューラがAPIを介し て入力および更新できる）を使用して、パケットフローを特定の消費コアにステアリングできます。[ 8 ] [ 7 ]

ソフトウェア技術

RPSやRFSなどのソフトウェア技術は、CPUコアの1つを使用して、着信パケットをプロセッサの他のコアに誘導します。これには、追加のプロセッサ間割り込み（IPI）が導入されるというコストがかかります。ただし、ハードウェア割り込みの数は増加せず、割り込み集約技術を使用することで、潜在的に削減される可能性があります。[ 13 ] ソフトウェアソリューションの利点は、現在使用されているアーキテクチャのコンポーネント（NICなど）を変更する必要がなく、適切なカーネルモジュールを展開するだけで実装が容易なことです。この利点は、サーバーマシンをカスタマイズまたはアクセスできない場合（クラウドコンピューティング環境など）に特に重要になり、ハードウェアでサポートされているものと比較してネットワークパフォーマンスが低下する可能性があります。[ 14 ] [ 15 ] [ 16 ]

RPS

RPS が CPU コア間で着信パケットを負荷分散する方法を示す図

受信パケットステアリング（RPS）は、ソフトウェアで実装されたRSSの並列処理です。NICが受信したすべてのパケットは、RSSと同様に、ヘッダーフィールド（レイヤー3の送信元IPと宛先IP、レイヤー4の送信元ポートと宛先ポートなど）を設定可能なキーとしてハッシュ関数を実装することで、コアのキュー間で負荷分散されます。さらに、ハッシュ特性により、同じフローに属するパケットは常に同じコアにステアリングされます。[ 15 ] これは通常、カーネル内で、NICドライバの直後に行われます。ネットワーク割り込みが処理された後、パケットはコアの受信キューに送信され、プロセス間割り込みによってコアに通知されます。[ 14 ] ハードウェアによって管理されるキューの数がコアの数よりも少ない場合、RPSはRSSと組み合わせて使用​​できます。この場合、受信パケットをRSSキューに分配した後、各キューにコアのプールを割り当て、RPSを使用して指定されたプールに受信フローを再び分散させます。[ 13 ]

RFS

RFSロジックが各着信パケットを対応するアプリケーションを実行しているコアに分配する方法を示す図

受信フローステアリング（RFS）は、aRFSハードウェアソリューションと同じ方向にRPSをアップグレードします。パケットフローを、消費アプリケーションを実行している同じCPUコアにルーティングすることで、キャッシュの局所性が向上し、キャッシュミスが回避され、中央メモリからデータを取得することによって発生するレイテンシが削減されます。[ 17 ] これを実現するために、現在のパケットのヘッダーフィールドのハッシュを計算した後、その結果を使用してルックアップテーブルをインデックスします。このテーブルはスケジューラによって管理され、アプリケーションプロセスがコア間で移動されると、スケジューラはそのエントリを更新します。[ 18 ]ユーザー空間 のアプリケーションが複数のコアに均等に分散されている限り、CPU負荷分散は全体的にバランスが取れています。[ 16 ] [ 18 ]

XPS（透過時）

送信パケットステアリング（XPS）は、これまで述べてきた他のプロトコルとは異なり、送信プロトコルです。パケットをNICによって公開される送信キューの1つにロードする必要がある場合、ここでも多くの最適化が可能です。[ 19 ] たとえば、1つのコアに複数の送信キューが割り当てられている場合、ハッシュ関数を使用して、送信パケットをキュー全体に負荷分散することができます（RPSが受信時に行うのと同様）。さらに、キャッシュの局所性とヒット率を向上させるために（RFSと同様）、XPSは、送信トラフィックを生成し、コアiで実行されるアプリケーションが、同じコアiに関連付けられた送信キューを優先することを保証します。これにより、コア間通信とキャッシュ一貫性プロトコルのオーバーヘッドが削減され、高負荷環境でのパフォーマンスが向上します。[ 20 ] [ 21 ] [ 2 ]

参照

参考文献

  1. ^ a b Barbette, Tom; Katsikas, Georgios P.; Maguire, Gerald Q.; Kostić, Dejan (2019-12-03). 「RSS++: 負荷と状態を考慮した受信側スケーリング」 . Proceedings of the 15th International Conference on Emerging Networking Experiments and Technologies . New York, NY, USA: Association for Computing Machinery. pp.  318– 333. doi : 10.1145/3359989.3365412 . hdl : 2078.1/262641 . ISBN 978-1-4503-6998-5。
  2. ^ a b Madden, Michael M. (2019-01-06)、「リアルタイム通信のためのLinuxネットワークスタックの使用における課題」、AIAA Scitech 2019フォーラム、AIAA SciTechフォーラム、アメリカ航空宇宙学会、pp.  9– 11、doi : 10.2514/6.2019-0503、ISBN 978-1-62410-578-4、 2025年7月10日閲覧{{citation}}: CS1 maint: ISBNによる作業パラメータ（リンク）
  3. ^ Herbert, Tom (2025年2月24日). 「受信パケットステアリングのアルファベットスープ：RSS、RPS、RFS、aRFS」 . Medium . 2025年7月10日閲覧。
  4. ^ a b「RSS kernel linux docs」 . kernel.org . Linuxカーネルドキュメント. 2025年7月8日閲覧。
  5. ^ a b「RSS の概要 (Microsoft による)」 . learn.microsoft.com . 2025年7月8日閲覧。
  6. ^ Wu, Wenji; DeMar, Phil; Crawford, Matt (2011-02-01). 「なぜ一部の高度なイーサネットNICはパケットの順序変更を引き起こすのか？」IEEE Communications Letters . 15 (2): 253– 255. arXiv : 1106.0443 . Bibcode : 2011IComL..15..253W . doi : 10.1109/LCOMM.2011.122010.102022 . ISSN 1558-2558 . 
  7. ^ a b「aRFS by redhat」 . docs.redhat.com . Red Hatドキュメント. 2025年7月8日閲覧。
  8. ^ a b c「aRFS by nvidea」 . docs.nvidia.com . NVIDIAドキュメントハブ. 2025年7月8日閲覧。
  9. ^ 「RSSインテルドキュメント」（PDF） . earn.microsoft.com . 2025年7月8日閲覧。
  10. ^ 「RSS by redhat」 . docs.redhat.com . Red Hatドキュメント. 2025年7月8日閲覧。
  11. ^ 「Windows Server 2008 の受信側スケーリング拡張機能」 . microsoft.com . Microsoft . 2025年7月8日閲覧。
  12. ^ "aRFS kernel linux docs" . kernel.org . Linuxカーネルドキュメント. 2025年7月8日閲覧。
  13. ^ a b「RPSカーネルLinuxドキュメント」 . kernel.org . Linuxカーネルドキュメント. 2025年7月8日閲覧。
  14. ^ a b Corbet, Jonathan (2009年11月17日). 「RPS Linux News (LWM)」 . lwn.net . Linux Weekly News . 2025年7月8日閲覧。
  15. ^ a b「RPS by redhat」 . docs.redhat.com . Red Hatドキュメント. 2025年7月8日閲覧。
  16. ^ a b「RFS by nvidea」 . docs.nvidia.com . NVIDIAドキュメントハブ. 2025年7月8日閲覧。
  17. ^ 「RFS by redhat」 . docs.redhat.com . Red Hatドキュメント. 2025年7月8日閲覧。
  18. ^ a b「RFSカーネルLinuxドキュメント」 . kernel.org . Linuxカーネルドキュメント. 2025年7月8日閲覧。
  19. ^ 「XPS Linuxニュース（LWM）」 lwn.net Linux Weekly News 2025年7月8日閲覧。
  20. ^ 「XPS intelの概要」 . intel.com . Intel corp . 2025年7月8日閲覧。
  21. ^ "XPS kernel linux docs" . kernel.org . Linuxカーネルドキュメント. 2025年7月8日閲覧。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Multi-core_network_packet_steering&oldid=1332523560#RSS」から取得