コミットログをチェックしていると、最近の10ギガビットNICやギガビットNICのデバイスドライバのコメントにTSOやLROといったコメントが入っていることに気がつく。これは命令の発行回数とキャッシュミスを減らすために、ネットワーク処理をCPUからNICデバイスで実施するというものだ。主に次の種類がある。
- 入出力のチェックサム処理をハードウェアで実施
- LRO (Large recieve offload) - セグメントの再構築をハードウェアで実施
- TSO (TCP segmentation offload) - TCPセグメンへの分割処理をハードウェアで実施
- TOE (Full TCP offload engine) - TCP/IPの処理をすべてハードウェアで実施
TSOはLSO (Large segment offload)やGSO (Generic segmentation offload)と呼ばれることもある。CPUの処理速度よりもNICの通信速度向上の方が早いため、処理をCPUで実施するよりもNICで実施した方が高速になるというのが最近のトレンドだ。特に10ギガビットNICやギガビットNICでこの機能が実装されている。
具体的には先に説明したTCP入出力処理の一部、または全部の処理をNICに委託することになる。次のそれぞれを見てみよう。
TCPチェックサムオフロード
TCPやUDP、IPのチェックサム処理をNICで実施する。これでCPU命令を削減できるほか、キャッシュミスも低下するという効果がでる。TCP受信時であればIPとTCPのチェックサム検証をNICで実施するようにする。送信時も同じくTCPとIPのチェックサム生成をハードウェアに移す。
送信処理の方にはソフトウェアに若干の変更が必要だ。TCPレイヤはチェックサムのオフロード機能がNICに存在するかを知らない。このためチェックサムをIP出力ルーチンまで遅延させるという変更がおこなわれている。
LRO (Large recieve offload)
TCPセグメントを再構築する処理をNICで実施する。TCPレイヤで実施していたTCPセグメントの再構築処理をNICとドライバに移行させ、処理を半分ハードウェアで担当するようにする。
TSO (TCP segmentation offload)
ある程度のデータそのままNICに送り込み、TCPセグメントへの分割をNICで実施する。
TOE (Fll TCP offload engine)
TOEではTCP処理のほとんどをNICに投げる。TOEに対応したNICの場合、受信処理ではカーネルは再構築されたあとのデータを取り出してmbufs+clustersからデータをコピーする処理しかおこなわない。送信する場合はカーネルはデータをmbufs+clustersにコピーしてそのままドライバに処理を移す。あとはNICが残りのすべての処理を実施する。
オフロードによる影響
NICオフロードは高速化に寄与する機能だが、レイヤ汚染がユーザにそれが伝わらないといった問題や、ハードウェアにバグが見つかった場合の回避手段の用意が困難であること、ネットワークスタックで実装していた各種フィルタリング機能が実現しにくくなるといった問題がある。