GRO（汎用受信オフロード）は、より高度なNICでどのように機能しますか？
私は特定の答えに興味があります：
- NICとGROはTCP ACKまたはその他のパケットを編集/作成しますか（またはこの機能はレシーバー/センダーTCPスタックに対して透過的ですか）？
- NICが「接着セグメント」をTCPスタックに渡す場合、タイムアウト/イベントが発生するはずですか？彼らは何ですか？
- パケット転送のセットアップで-GRO機能は受信側ACKも読み取ろうとしますか（なぜ私がこれを要求しているのか以下を参照してください）？
- ウィキペディアやLinuxのmanページよりも優れたGROおよびその他のNICオフロード機能（TSO、LSO ...）について説明しているソースがあれば、本当にありがたいです。
詳細：
1つのIPSec実装でパフォーマンスの問題をトラブルシューティングしています。問題は、利用可能な帯域幅が4つのVPNトンネルすべてに均等に分散されていないことです（約200MBps/200MBps/1MBps/1MBpsとして分散。各VPNトンネルは単一のTCP接続をカプセル化します）。 PCAPでは時々、Webサーバーが約2秒間アイドル状態になる（ACKを待機している）ことがわかります。 Webサーバーが未確認のセグメントを再送信すると、ダウンロードが再開されます。
PCAPからの私の内部の問題は、NIC GRO機能がパケットを接着するが、時々それらをTCPスタックに渡さず、それが問題を引き起こしていることです。
このVPNサーバーには、TCP接続を終了するインターフェイスがなく、パケットを転送するだけなので、次に、GROを無効にしてみましたが、その後、トラフィックがすべてのトンネルに均等に分散されていることがわかりました。また、WebサーバーでTCPウィンドウスケーリングが無効になっている場合、GROを有効にしても帯域幅が分散されます（そのため、質問＃3を行いました）。
Ubuntu 10.04サーバー（64ビット）で2.6.32-27 linuxを使用しています。 NICはIntel 82571EBです。すべてのインターフェース（HTTPクライアント、VPNクライアント、VPNサーバー、ウェブサーバー）は、1ギガビットイーサネットケーブルでチェーンに直接接続されています。
私はこの記事が驚くほど役立つとわかりました： JLS2009：Generic receive offload 。 GROがどのように機能するかについての概要がわかります。
- 一部のアダプタはそれを行うかもしれませんが、関連するドライバもそれを認識する必要があります。また、ドライバー自体がソフトウェアでこれを行うことができます。これはカーネルTCP/IPスタックに入る前に発生するため、カーネルスペースTCP/IPスタックに完全に入るときまでに、パケットは再シーケンスされています。
- タイムアウトは、GRO仕様で1つのTCP/IPの「ティック」（タイムスタンプフィールドの増分）として定義されています。これは非常に小さい数値ですが、高速ネットワークでは複数のパケットを引き続き受信できます。
- GROはフォワーダーの受信側で機能し、実際にはGROが作成されたので、より貪欲なLROメソッドはフォワーダーでのパケットのねじ込みを停止します。
- 上記にリンクした記事は本当に役に立ちます。
Ethtool may特定のインターフェースでGROを有効/無効にすることができます。バージョンによって異なります。