ethtool/tcオフロード設定の本番チューニング｜NIC交換後の性能劣化診断と復旧手順

NIC交換後に性能が落ちる「見えにくい原因」

ハードウェア更改の直後にネットワーク性能が劣化するケースは現場で珍しくありません。新しいNICを搭載してドライバを入れ替えたところ、iperf3の測定値が以前の半分以下になった、あるいはWebアプリのレスポンスタイムが跳ね上がったという事例が報告されています。

こうした劣化の原因として真っ先に疑うべきなのが、NICのオフロード機能の設定差異です。オフロード機能とは、TCP/UDPのチェックサム計算・セグメント分割・再組み立てといった処理をCPUではなくNICのハードウェアに委譲する仕組みを指します。旧NICで有効になっていたオフロードが新NICで無効のまま放置されると、CPUサイクルが通信処理に食われてアプリケーションの処理能力が低下します。逆に、ハードウェアが対応していないオフロードを無理に有効化するとパケット破損や予期しない再送が起きることもあります。

見落とされがちな理由は、デフォルト設定がNICモデルやドライババージョンによって異なるためです。同じ「1Gbps NIC」に見えても、Intelのixgbeドライバとカーネル内蔵のe1000eドライバでは初期値が別物です。交換前後でethtoolの出力を比較していない限り、設定差異は見えません。

ethtoolで現在のオフロード状態を診断する

診断の出発点はethtoolによる現状確認です。対象インタフェースをeth0として説明しますが、実環境ではip linkやnmcli deviceで正確な名前を確認してください。

# オフロード機能一覧の確認
ethtool -k eth0

# NIC自体のハードウェア能力を確認（対応可否）
ethtool -i eth0       # ドライバ情報
ethtool eth0          # リンク速度・デュプレックス

ethtool -kの出力には数十項目が並びます。運用上まず確認すべき項目を以下に示します。

• tx-checksumming / rx-checksumming：送受信チェックサムのNICへの委譲。無効だとCPUがすべて計算する。
• tcp-segmentation-offload（TSO）：大きなTCPペイロードをNICが分割してMTU内に収める機能。無効だとカーネルが分割する。
• generic-segmentation-offload（GSO）：ソフトウェア実装のセグメント遅延処理。TSOが使えない場合のフォールバック。
• generic-receive-offload（GRO）：受信側で小さなパケットをまとめてアプリに渡す処理。無効だと割り込み数が増加する。
• large-receive-offload（LRO）：GROのハードウェア版。ドライバ依存で無効が推奨される場面もある。

出力行末の[fixed]はハードウェアが変更を受け付けないことを示します。on [fixed]やoff [fixed]と表示された項目は変更不可なので、診断時に混同しないよう注意が必要です。

旧NICとの設定差異を素早く見つける方法

交換前のNICのethtool出力をログに残していない場合でも、同一モデルの別ホストと比較することで差異を検出できます。以下のようにgrepとsortを組み合わせると設定の並び順を揃えて差分比較できます。

# 新旧ホストでそれぞれ実行してファイルに保存
ethtool -k eth0 | sort > /tmp/offload_new.txt
# 別ホストから取得した出力と比較
diff /tmp/offload_old.txt /tmp/offload_new.txt

オフロード設定の変更と性能への影響

設定変更はethtool -K（大文字K）で行います。変更は即時反映されますが、再起動後にリセットされるため、この段階ではあくまで動作確認用の試験変更として扱うことを推奨します。

# TSOを有効化する例
ethtool -K eth0 tso on

# GROを無効化する例（仮想化環境では推奨されることがある）
ethtool -K eth0 gro off

# 複数項目をまとめて変更
ethtool -K eth0 tso on gso on gro on rx on tx on

変更後はiperf3やnetperfで定量的に効果を測定します。スループット重視の場合はTSO・GSOの有効化が有効で、レイテンシ重視または仮想化（KVM/Xen）環境では逆にGROやLROを無効化した方が安定することが知られています。

なお、LROについては一部のドライバでルーティング環境との相性問題が報告されています。Linuxルータとして動作するホストでLROを有効にするとパケットのTTL計算が狂うケースがあるため、ルータ用途ではlro offを標準設定とする運用が広まっています。

tcコマンドによるハードウェアオフロードの制御

iproute2のtcコマンドはQoSやトラフィックシェーピングだけでなく、NICが対応していればフィルタリングルールをハードウェアにオフロードする機能も持っています。この機能は「TCハードウェアオフロード」または「フローオフロード」と呼ばれ、高スループット環境でのCPU負荷削減に効果的です。

確認と設定の基本的な流れは以下のとおりです。

# NICがTCオフロードに対応しているか確認
ethtool -k eth0 | grep hw-tc-offload

# TCオフロードを有効化
ethtool -K eth0 hw-tc-offload on

# ingress qdisc をアタッチ（TCオフロードの前提）
tc qdisc add dev eth0 ingress

# フィルタをハードウェアオフロードで追加（skipswオプション）
tc filter add dev eth0 ingress protocol ip prio 1 \
  flower dst_ip 192.0.2.0/24 action drop hw_stats immediate

NIC交換後にTCオフロードが意図せず無効になっていると、以前は問題なかったフィルタルールがすべてソフトウェア処理に落ちてCPU使用率が急上昇するという現象が起きます。tc -s filter show dev eth0 ingressの出力でhwフラグが表示されているかを確認することで、ハードウェアオフロードが実際に機能しているかを検証できます。

XDP（eXpress Data Path）との関係

2026年時点では、高性能NIC（Mellanox/ConnectX-6以降、Intel E810など）でXDPオフロードモードが実用段階に入っています。XDPはTCよりもさらに早いパケット処理パスを提供しますが、NIC交換時にXDP対応の有無が変わると既存のeBPFプログラムが動作しなくなる点に注意が必要です。ip link set dev eth0 xdpで設定したXDPプログラムのアタッチ状態はip link show eth0の出力で確認できます。

設定の永続化と切り戻し手順

試験変更で効果が確認できたら永続化に進みます。systemd-networkdを使っている環境では.networkファイルの[Link]セクションに記述する方法が現行標準です。

# /etc/systemd/network/10-eth0.network の例
[Match]
Name=eth0

[Link]
# 必要に応じてオフロード設定を追加

[Network]
DHCP=no
Address=192.0.2.10/24

ただし、systemd-networkdの[Link]セクションは2026年現在のバージョンでもオフロード設定の全項目をカバーしているわけではありません。対応していない項目は/etc/udev/rules.d/にudevルールとして記述するか、NetworkManagerを使う環境であればdispatcherスクリプトでethtool -Kを呼び出す方法が現実的です。

# udevルールによる永続化の例
# /etc/udev/rules.d/99-ethtool-offload.rules
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth0", \
  RUN+="/usr/sbin/ethtool -K eth0 tso on gso on gro on"

切り戻し手順としては、変更前の設定をファイルに記録しておくことが重要です。以下のワンライナーで変更前後のスナップショットを取得しておくと、トラブル時の原因特定と復旧が大幅に楽になります。

# 変更前スナップショット
ethtool -k eth0 > /root/offload_before_$(date +%Y%m%d).txt

# 切り戻し（例：TSOを無効に戻す）
ethtool -K eth0 tso off

2026年の現行環境で押さえるべき差分と注意点

カーネル6.x系以降でオフロード周りの挙動に変化が生じている点をいくつか整理します。

まずGSOの扱いです。カーネル6.4以降、GSO_MAX_SIZEのデフォルト値が変更されており、古いNICドライバと組み合わせると予期しないセグメント分割サイズになる場合があります。ip link show eth0でgso_max_sizeとgso_max_segsの値を確認し、アプリケーションのMTU設定と整合性が取れているかを確認することを推奨します。

次に、NetworkManagerのバージョン1.44以降ではnmcli connection modifyでethtoolオフロード設定を直接記述できるようになっています。RHELおよびUbuntu 24.04 LTS以降の標準環境ではNetworkManagerが主流であるため、udevルールよりもNetworkManagerのconnectionファイルで管理する方がライフサイクル管理が一元化できます。

# NetworkManager経由でのオフロード設定（NM 1.44以降）
nmcli connection modify eth0 ethtool.feature-tso on
nmcli connection modify eth0 ethtool.feature-gro on
nmcli connection up eth0

また、SR-IOV（Single Root I/O Virtualization）対応NICでは、VF（仮想ファンクション）ごとにオフロード設定が独立して管理されます。ホスト側のPFにethtool -Kを適用してもVFには反映されないため、仮想化ホストでNIC交換を行った際はVFの設定も個別に確認することが必要です。

NIC交換という単純に見える作業でも、オフロード設定の差異が本番性能に直結するのがLinuxネットワークの難しさです。ethtool -kとtc -sによる状態確認を交換前後のチェックリストに組み込み、設定スナップショットを残す習慣を持つことが、予期しない性能劣化を防ぐ最も確実な方法です。