GRO/GSO/TSO：セグメンテーションオフロードの原理

なぜパケット数そのものがコストになるのか

TCP/IPの送受信コストは、転送する バイト数 よりも パケット数 に強く比例します。1パケットを処理するたびに、IP/TCPヘッダの生成や検査、チェックサム計算、ルーティング・ネットフィルタの通過、ソケットバッファとの受け渡し、そしてプロトコルスタックを一段ずつ降りる/昇る関数呼び出しが発生するからです。これらは概ね「1パケットあたり固定費」で、ペイロードが小さくても大きくても大差ありません。

ここでイーサネットのMTU（標準1500バイト）が効いてきます。MTUとMSS（TCPが1セグメントに載せる最大データ量）の関係は MTU（最大転送単位）とは の通りで、標準MTUなら1セグメントは約1460バイトです。10Gbpsを標準MTUで埋めると毎秒80万パケットを超え、固定費がCPUを食い潰します。データ量ではなくパケット数が律速 になる——これがオフロードの出発点です。

送信オフロード：分割を最後に委ねる（TSO/GSO）

送信側の発想は「スタックの中ではできるだけ大きな塊のまま運び、MSSへの分割は最後の最後に行う」ことです。アプリが64KBを send() したとき、素朴な実装はスタックの上流で1460バイトごとに約45個のセグメントへ刻み、その45個それぞれにヘッダ生成・チェックサム・スタック通過のコストを払います。

TSO（TCP Segmentation Offload） は、この分割を NICのハードウェア へ委ねます。スタックは64KBの巨大セグメントを1つの単位として扱い、テンプレートとなるTCP/IPヘッダを1つ付けてNICへ渡すだけ。NICが送出直前にそれをMSSごとの実フレームへ刻み、各フレームのシーケンス番号・チェックサム・長さフィールドを埋めます。スタックを通る単位が1/45になるので、ホスト側の固定費が劇的に減ります。

TSOなし: アプリ64KB → スタックが45個に分割 → 45回ぶんのヘッダ生成/checksum/スタック通過 → NIC
TSOあり: アプリ64KB → スタックは1個のまま処理 → NICが送出時に45個へ分割

GSO（Generic Segmentation Offload） は同じ発想をソフトウェアで実現する一般化です。NICがTSO非対応でも、あるいはトンネル等で複雑な場合でも、分割をスタックの できるだけ下流（デバイスへ渡す直前） まで遅らせます。NICがハードウェア分割できるならそこで委ね、できなければ直前にソフトウェアで分割する。GSOは「分割の遅延」という原理だけを取り出した枠組みで、TSOはそのハードウェア実装と捉えると整理できます。チェックサム計算自体をNICへ任せる チェックサムオフロード も併用され、send() から recv() までのデータ移動を最小化する ソケットバッファとゼロコピー送受信 と組み合わせて送信パスのCPU効率を上げます。

受信オフロード：連続セグメントを束ねる（GRO/LRO）

受信側は逆向きの最適化です。回線からはMSSサイズの小さなフレームが大量に届きますが、それを1個ずつスタックへ上げると、やはりパケット数ぶんの固定費がかかります。そこで 受信側で連続するセグメントを束ねてから スタックへ渡します。

GRO（Generic Receive Offload） は、同一フロー（同じ5タプル）に属し、シーケンス番号が連続する複数のセグメントを、ソフトウェアで1つの巨大なバッファ（最大64KB相当）に マージ します。スタックはその巨大セグメントを1単位として処理するので、IP/TCP処理やソケットへの受け渡しが1回で済みます。受信処理の文脈は カーネルのパケット受信経路：NAPIと割り込み緩和 の通りで、GROはNAPIの poll() がリングから刈り取った直後、まだソフトIRQの中にいる段階で束ねが行われます。1回のポーリングでまとめて取り出したパケット群を、フローごとに合体させるわけです。

マージできるのは厳密な条件を満たすときだけです。同一フローで、シーケンスが隙間なく連続し、TCPフラグやオプション（タイムスタンプ等）が整合し、合体しても64KBを超えない——この条件を外れると、GROはそこで束ねを打ち切って現在の塊をスタックへ吐き出します（フラッシュ）。だから順序が乱れたり別フローが混ざると、束ねは小さい単位で切れます。

計測への影響：見かけと実体がズレる

オフロードを理解していないと、計測が必ず誤読を招きます。最大の罠は tcpdump（libpcap）が見るのはオフロード処理の「ホスト内部」側 だという点です。tcpdumpはスタックの入口（送信ではデバイスへ渡す直前、受信ではGRO束ね後）でパケットをキャプチャするため、TSO/GSOやGROで作られた MTUを大きく超える巨大パケット（数KB〜64KB）がそのまま表示されます。

tcpdump が表示する length: 28960  ← GROで束ねられた見かけのサイズ
実際に回線を流れるフレーム:        1500バイト × 約20個

つまり「キャプチャ上の1パケット」と「ワイヤ上の1フレーム」は一致しません。1パケットあたりのMSSや、実際のパケット数・ペース（パケット間隔）を回線レベルで見たいなら、tcpdumpの値を鵜呑みにせず、ethtool -K で該当機能を一時的に無効化するか、回線上で観測する必要があります。

実用上の害もあります。TSO/GSOで巨大な塊を一気にNICへ渡すと、回線へは短時間にバースト状に送出されやすく、これがTCPのペーシングや小さいバッファと相性が悪い場面があります。逆にGROは束ねるぶん、個々のセグメントのACK生成が遅れたりRTT計測がわずかにブレ得ます。多くの場合オフロードはCPU節約の利得が圧倒的に勝ちますが、低遅延が至上命題の用途や精密なRTT計測では、意図的に切る判断もあります。フロー制御・ウィンドウの挙動を精密に追うときは TCPのフロー制御とウィンドウスケーリング と合わせ、オフロードの有無を意識する必要があります。

まとめ

TCP/IP処理のコストはバイト数よりパケット数に比例し、高帯域では標準MTUゆえにパケット数が律速になります。送信側のTSO/GSOは、64KBの巨大セグメントをスタックに通し、MSSへの分割を最後にNIC（TSO）または送出直前のソフトウェア（GSO）へ委ねることで、ホスト側のヘッダ生成・チェックサム・スタック通過の回数を激減させます。受信側のGRO/LROは、同一フローの連続セグメントを巨大バッファへ束ねてから1回でスタックへ上げ、GROは元の境界を復元できる可逆設計ゆえ転送・ブリッジでも安全（LROは不可逆で転送に不向き）です。いずれも回線のMTU/MSSは変えず、ホスト内部の処理単位だけを大きくする最適化なので、tcpdumpにはMTU超の巨大パケットが見える——この「見かけと実体のズレ」を理解することが、オフロード環境での計測とトラブル切り分けの要です。