TSO、GRO、RSS 機能

このセクションでは、TSO、GRO、RSS、複数のディスパッチャーとキューなど、SE グループの機能について説明します。

TCP セグメンテーションオフロード (TSO)

TCP セグメンテーションオフロードは、高速ネットワーク上の TCP/IP の CPU オーバーヘッドを削減するために使用されます。TSO が有効なハードウェアを持つホストは、ソフトウェアのデータをセグメント化せずに TCP データをネットワークインターフェイスカード (NIC) に送信します。このタイプのオフロードは、NIC を使用してデータをセグメント化し、TCP、IP、およびデータリンクレイヤーヘッダーを各セグメントに追加します。

ルーティングでの TSO サポート

SE でルーティングサポートが有効になっている場合、汎用受信オフロード (GRO) 機能は使用できません。これは、ルーティングはステートレスであり、パケットの IP フラグメント化が許可されていない場合、SE は GRO で一体化された大きなパケットをセグメント化できないためです。この機能のサポートの結果として、GRO をルーティングトラフィックに使用できます。これにより SE は、インターフェイスでサポートされている場合は TSO を介して、または SE のルーティングレイヤーを介して、より大きなパケットをより小さな TCP セグメントにセグメント化できます。

3 ウェイハンドシェイク中に、クライアントとサーバの両方がそれぞれの MSS をアドバタイズし、ピアが MSS よりも大きい TCP セグメントを送信しないようにします。これはデフォルトで有効です。

汎用受信オフロード (GRO)

GRO は、CPU のオーバーヘッドを削減することで、広帯域ネットワーク接続の受信スループットを向上させるソフトウェア技術です。これは、単一のフローからの複数の受信パケットを、ネットワークスタックの上位に渡される前により大きなパケットチェーンに集約することによって機能し、その結果、処理する必要があるパケットの数を減らします。

注：

GRO は、同じフローの複数のパケットが短期間に受信された場合に使用されます。受信パケットが異なるフローに属している場合、GRO を有効にしてもメリットがない場合があります。

DPDK ライブラリでの GRO 操作の 2 つのモードは次のとおりです。

スタティックモード：: 1 回のバーストで受信されたパケットには GRO レイヤーが適用されます。これは、バージョン 22.1.1 より前の NSX Advanced Load Balancer での操作モードです。
タイマーモード：: 受信したパケットには、構成されたタイムアウトに対して GRO レイヤーが適用されます。SYN、PSH、RST などの特別なパケットには、このタイムアウトは適用されません。

GRO はタイマーモードに基づいています。タイマーモード GRO はパフォーマンスを向上させ、スタティックモード GRO と比較して CPU 使用率を削減できます。

タイムアウト値は、dpdk_gro_timeout_interval の ServiceEngineGroup で構成できます。デフォルトの GRO タイムアウト値は、新しいサービスエンジングループの場合 50us です。このノブは、0 ～ 900us の範囲で変わる場合があります。dpdk_gro_timeout_interval がゼロに設定されている場合、サービスエンジングループ内の SE は GRO のスタティックモードに戻ります。SE を 22.1.1 にアップグレードすると、dpdk_gro_timeout_interval がゼロになり、レガシーモードの操作であるバーストモード GRO であることを示します。

NSX Advanced Load Balancer バージョン 22.1.2 以降では、SE グループに 8 個以上の vCPU を持つ SE がある場合、GRO が有効になります。

マルチキューのサポート

NSX Advanced Load Balancer のディスパッチャーは、NIC から受信パケットを取得し、プロキシ処理のために適切なコアに送信し、送信パケットを NIC に送信します。たとえば、UDP パケットが小さい場合、1 秒あたりのパケット数 (PPS) の大きいトラフィックを受信する 40G NIC あるいは 10G NIC は、シングルコアディスパッチャーでは効率的に処理されない可能性があります。

この問題は、単一の物理 NIC からのトラフィックを複数のキューに分散し、各キューが異なるコアのディスパッチャーによって処理されるようにすることで解決できます。Receive Side Scaling (RSS) を使用すると、単一の物理 NIC で複数のキューを使用できます。

Receive Side Scaling (RSS)

NSX Advanced Load Balancer で RSS が有効になっている場合、NIC は受信パスで複数のキューを使用します。NIC はフローをキューに固定し、使用する同じフローに属するパケットを同じキューに配置します。これにより、ドライバは複数の CPU にパケット処理を分散できるため、効率が向上します。

NSX Advanced Load Balancer SE では、マルチキュー機能が送信側でも有効になります。つまり、異なるフローが異なるキュー（同じキュー内の同じフローに属するパケット）に固定され、CPU 間でパケット処理が分散されます。

注：

IPv6 アドレスでは、マルチキュー機能 (RSS) はサポートされません。RSS が有効になっている場合、NSX Advanced Load Balancer サービスエンジンインターフェイスに IPv6 アドレスを構成できません。同様に、IPv6 アドレスが NSX Advanced Load Balancer サービスエンジンインターフェイスですでに構成されている場合、これらのインターフェイスでマルチキュー機能 (RSS) を有効にすることはできません。

NIC ごとに複数のディスパッチャーとキュー

サービスエンジンによって処理されるトラフィックに応じて、ディスパッチャーの数を 1 つ以上のコアで構成できます。PPS 負荷の高いシステムは多数のディスパッチャーで構成されていますが、SSL ワークロードなど、プロキシの負荷が高い場合は、多数のディスパッチャーを必要としないことがあります。

また、パフォーマンスを向上させるために、各ディスパッチャーコアに NIC ごとのキューを設定できます。サービスエンジンは、環境ごとに最適な設定を自動的に検出しようとします。

サービスエンジンのデータパスの隔離モード

NSX Advanced Load Balancer サービスエンジンは、1 つ以上のサービスエンジンコアを se-dp 以外のタスク専用にすることができます。この構成は、サービスエンジンが遅延の影響を受けやすいアプリケーションをホストしている場合に特に役立ちます。また、1 つ以上のコアが se-dp 以外のタスク専用のため、サービスエンジンのパフォーマンス全体にペナルティが課されます。

ハイブリッド RSS モード

SE ハイブリッド RSS モードは、RSS が構成された DPDK モードでのみ機能し、各 SE vCPU を独立したユニットとして機能させることができます。これにより、すべてのコアがディスパッチジョブとプロキシジョブを同時に処理でき、パケットがコア間でパントされないようにします。すなわち、2 コアサービスエンジンの場合は、それぞれ vCPU0 および vCPU1 の (dispatcher-0, proxy-0)、(dispatcher-1, proxy-1) としてタグ付けされ、dispatcher-0 の入力方向フローは proxy-0 を介して出力され、proxy-1 にパントされません。その逆も同様です。

ハイブリッドモードは構成可能なプロパティとして取り込まれ、低コア SE、特に vCenter Server/NSX-T クラウド上の 1 コアと 2 コア SE で高いパフォーマンスを実現することを目的としています。

パブリッククラウドの自動 RSS

パブリッククラウド上の仮想マシンにプロビジョニングされるネットワーク帯域幅（キャパシティ）は、接続されたネットワークインターフェイスの合計ネットワーク帯域幅ではなく、インスタンスタイプによって決まります。SE は、そのインスタンスタイプの公開ネットワークキャパシティを決定し、RSS、すなわち max_queues_per_vnics と num_dispatcher_cores を自動モードで適切に構成します。管理者は値を手動で構成できます。これらのノブを更新するには、再起動が必要です。

トラフィックプロファイルに応じて、専用ディスパッチャーモードを有効にすることもできます。これはランタイムプロパティであり、dedicated_dispatcher_core（ブール値）ノブを使用して切り替えることができます。

アップグレードに関する考慮事項

将来のリリースでは、新しい SE グループに対して自動 RSS 機能を「自動 (0)」に構成できます。

注：

以前の構成はアップグレード後も保持されます。

TCP セグメンテーション オフロード (TSO)