VXLANとGeneveでBIG TCPを利用可能に

Linux 7.3では、BIG TCPがVXLANおよびGeneveのUDPトンネルドライバーでも利用できるようになります。BIG TCPは、カーネル内部で64KiBを超える大きなペイロードをまとめて処理し、実際にネットワークへ送出する前にGSOやTSOで分割する仕組みです。ネットワーク上に規格外の巨大パケットを流すのではなく、オーバーレイ経路で発生するパケット単位の処理負荷を減らすことを狙っています。

報告されたnetperf TCP_STREAMの測定結果は、次の通りです。

• 標準MTUのVXLANでは、34.44Gbpsから39.56Gbpsへ上昇し、14.9％向上
• トンネルのハードウェアオフロードを無効にしたVXLANでは、21.82Gbpsから29.39Gbpsへ上昇し、34.7％向上
• 標準MTUのGeneveでは、37.39Gbpsから40.89Gbpsへ上昇し、9.4％向上

ここで注意したいのは、これらが特定の構成で得られた数値だという点です。gso_max_sizeやgro_max_size、NICの機能、オフロード設定、MTU、トンネルの種類、ワークロードなどによって結果は変わります。VXLANやGeneveを運用する管理者は、Linux 7.3へ移行する前に自分の環境でベンチマークを行うべきでしょう。

FIBルール更新でRTNLロックの競合を緩和

IPv4およびIPv6のFIB（転送情報ベース）ルールを追加・削除する処理では、幅広い範囲を直列化するRTNLロックへの依存が減らされました。可能な場合は、関連するfib_rules_opsに紐づくミューテックスで保護することで、複数の処理を並行して進められるようにしています。なお、IPv4の最初のルールにおけるfib_unmerge()経路など、一部では引き続きRTNLが必要です。

極端に高い並列性を想定した合成テストでは、4,096個のネットワーク名前空間を作成し、それぞれに1,024個のルールを並行して追加する処理が、IPv4で22.752秒から0.918秒へ短縮されました。これは約24.8倍の高速化です。IPv6でも35.181秒から1.214秒となり、約29.0倍速くなっています。

もっとも、この結果は大量の名前空間操作による激しいロック競合を測ったものです。通常のコンテナー起動や、あらゆるルーティング処理が同じ倍率で高速化することを意味しません。

AI生成パッチの急増に、複数モデルで対応

今回のマージで、技術面と同じくらい注目を集めているのが、Linuxカーネル開発におけるAI活用の試みです。

ネットワークサブシステムのメンテナーであるJakub Kicinski氏は、net向けに632件、net-next向けに648件のパッチがあると報告しました。さらに、net-nextの約3分の1から2分の1が、AIによって作られた低優先度の修正、コード整理、説明の明確化などだと推計しています。単純計算では、およそ216件から324件に相当します。Kicinski氏とPaolo Abeni氏は、この状況について「完全に圧倒されている」と表現しました。

対応策として検討されているのは、単一のAIモデルにレビューを任せることではありません。Metaが複数の最先端モデルを利用するための予算とアクセスを提供し、各パッチを複数モデルで一次確認する構想です。ひとつのモデルによる幻覚や誤解釈が、そのまま開発プロセスを通過するリスクを抑える狙いがあります。

自動化の候補には、Patchworkの管理、定型的な開発手順に関するフィードバック、コミットメッセージの編集、信頼できる開発者がすでにレビューしたパッチの適用などが挙げられています。こうした作業は、珍しい障害経路の正しさを判断するよりも、構造化しやすい領域です。

一方で、カーネルネットワークでは人間の判断が欠かせない場面もあります。例えば、まれな競合状態や、PCIeエラー、タイムアウト処理といったハードウェア復旧経路です。AIは反復的な確認作業を減らせても、並行処理、APIの契約、復旧手順の順序まで理解したうえで安全性を保証するものではありません。

新ドライバーとプロトコル関連の変更

ネットワーク関連のマージには、次のようなハードウェア対応も含まれています。

• Morse MicroのWi-Fi HaLow向け初期mm81xドライバー。USBおよびSDIOデバイスに対応
• NXPの新しい無線ドライバーNXPWIFI。マルチリンク動作の開発も継続
• IntelのE2100以降のIPUおよびFNICでControl Plane PIC Functionをサポートする、初期段階のiXDドライバー骨格
• AMD／Solarflare NIC向けの初期CXL対応
• AMD Pensandoハードウェア向けのファームウェア書き込み対応

プロトコル周りでは、MPTCPに極端なメモリー不足が発生した場合、順序が入れ替わったパケットのキューを最後の手段として削減する仕組みが加わります。通常時のスループットを高める機能というより、厳しいメモリー制約下で復旧や再送を可能にするための対策です。

AF_UNIXのファイルディスクリプター受け渡しも診断しやすくなります。SCM_RIGHTS配列に含まれる特定のファイルディスクリプターをLSM（Linux Security Module）が拒否した場合、SO_RIGHTS_NOTRUNCを使えば、受信側で拒否されたディスクリプターとerrnoを確認できます。最初の拒否で配列の残りまで失われる問題を避けるための改善です。

Linux 7.3はいつ利用できるのか

最初のLinux 7.3リリース候補版は2026年8月30日頃、安定版は通常の開発スケジュールが維持されれば10月下旬に登場すると予測されています。

ただし、安定版が公開された直後に、多くのサーバーやデスクトップへこれらの機能が届くとは限りません。各Linuxディストリビューションは、採用するカーネルを独自に選び、必要な変更をバックポートし、テストしたうえで別々のスケジュールで配布します。ローリングリリース型のディストリビューションは早く採用する可能性がありますが、固定リリース型ではさらに時間がかかることがあります。

Arch Linuxベースのローリング型ディストリビューションであるCachyOSは、早期採用候補のひとつと考えられます。しかし、2026年8月のリリース情報ではLinux 7.3の採用時期は確認されておらず、インストールイメージはLinux 7.1を使用していました。

インフラ運用者と開発者にとっての意味

インフラ運用者にとって、まず確認したいのはBIG TCPによるオーバーレイ経路の改善と、大量のネットワーク名前空間を同時に設定する際の競合緩和です。特に、VXLANやGeneve上で高スループット通信を行う環境、あるいは多数の名前空間を並行して作成・設定する環境では、実測する価値があります。

カーネル開発者にとっては、AIによるレビュー実験も重要な意味を持ちます。今回の動きが示しているのは、AIに開発全体を任せることではなく、反復的なトリアージや手続き上のフィードバックをモデルに担わせ、デッドロックや復旧処理の誤りにつながりかねない難しいケースはメンテナーが判断するという役割分担です。

Linux 7.3のネットワーク機能は大きく前進しますが、一般ユーザーが実際に利用できるようになるまでには、リリース候補版でのテスト、ハードウェア検証、ディストリビューション側の統合作業が残されています。

VXLANとGeneveでBIG TCPを利用可能に

Linux 7.3では、BIG TCPがVXLANおよびGeneveのUDPトンネルドライバーでも利用できるようになります。BIG TCPは、カーネル内部で64KiBを超える大きなペイロードをまとめて処理し、実際にネットワークへ送出する前にGSOやTSOで分割する仕組みです。ネットワーク上に規格外の巨大パケットを流すのではなく、オーバーレイ経路で発生するパケット単位の処理負荷を減らすことを狙っています。

報告されたnetperf TCP_STREAMの測定結果は、次の通りです。

• 標準MTUのVXLANでは、34.44Gbpsから39.56Gbpsへ上昇し、14.9％向上
• トンネルのハードウェアオフロードを無効にしたVXLANでは、21.82Gbpsから29.39Gbpsへ上昇し、34.7％向上
• 標準MTUのGeneveでは、37.39Gbpsから40.89Gbpsへ上昇し、9.4％向上

ここで注意したいのは、これらが特定の構成で得られた数値だという点です。gso_max_sizeやgro_max_size、NICの機能、オフロード設定、MTU、トンネルの種類、ワークロードなどによって結果は変わります。VXLANやGeneveを運用する管理者は、Linux 7.3へ移行する前に自分の環境でベンチマークを行うべきでしょう。

FIBルール更新でRTNLロックの競合を緩和

IPv4およびIPv6のFIB（転送情報ベース）ルールを追加・削除する処理では、幅広い範囲を直列化するRTNLロックへの依存が減らされました。可能な場合は、関連するfib_rules_opsに紐づくミューテックスで保護することで、複数の処理を並行して進められるようにしています。なお、IPv4の最初のルールにおけるfib_unmerge()経路など、一部では引き続きRTNLが必要です。

極端に高い並列性を想定した合成テストでは、4,096個のネットワーク名前空間を作成し、それぞれに1,024個のルールを並行して追加する処理が、IPv4で22.752秒から0.918秒へ短縮されました。これは約24.8倍の高速化です。IPv6でも35.181秒から1.214秒となり、約29.0倍速くなっています。

もっとも、この結果は大量の名前空間操作による激しいロック競合を測ったものです。通常のコンテナー起動や、あらゆるルーティング処理が同じ倍率で高速化することを意味しません。

AI生成パッチの急増に、複数モデルで対応

今回のマージで、技術面と同じくらい注目を集めているのが、Linuxカーネル開発におけるAI活用の試みです。

ネットワークサブシステムのメンテナーであるJakub Kicinski氏は、net向けに632件、net-next向けに648件のパッチがあると報告しました。さらに、net-nextの約3分の1から2分の1が、AIによって作られた低優先度の修正、コード整理、説明の明確化などだと推計しています。単純計算では、およそ216件から324件に相当します。Kicinski氏とPaolo Abeni氏は、この状況について「完全に圧倒されている」と表現しました。

対応策として検討されているのは、単一のAIモデルにレビューを任せることではありません。Metaが複数の最先端モデルを利用するための予算とアクセスを提供し、各パッチを複数モデルで一次確認する構想です。ひとつのモデルによる幻覚や誤解釈が、そのまま開発プロセスを通過するリスクを抑える狙いがあります。

自動化の候補には、Patchworkの管理、定型的な開発手順に関するフィードバック、コミットメッセージの編集、信頼できる開発者がすでにレビューしたパッチの適用などが挙げられています。こうした作業は、珍しい障害経路の正しさを判断するよりも、構造化しやすい領域です。

一方で、カーネルネットワークでは人間の判断が欠かせない場面もあります。例えば、まれな競合状態や、PCIeエラー、タイムアウト処理といったハードウェア復旧経路です。AIは反復的な確認作業を減らせても、並行処理、APIの契約、復旧手順の順序まで理解したうえで安全性を保証するものではありません。

新ドライバーとプロトコル関連の変更

ネットワーク関連のマージには、次のようなハードウェア対応も含まれています。

• Morse MicroのWi-Fi HaLow向け初期mm81xドライバー。USBおよびSDIOデバイスに対応
• NXPの新しい無線ドライバーNXPWIFI。マルチリンク動作の開発も継続
• IntelのE2100以降のIPUおよびFNICでControl Plane PIC Functionをサポートする、初期段階のiXDドライバー骨格
• AMD／Solarflare NIC向けの初期CXL対応
• AMD Pensandoハードウェア向けのファームウェア書き込み対応

プロトコル周りでは、MPTCPに極端なメモリー不足が発生した場合、順序が入れ替わったパケットのキューを最後の手段として削減する仕組みが加わります。通常時のスループットを高める機能というより、厳しいメモリー制約下で復旧や再送を可能にするための対策です。

AF_UNIXのファイルディスクリプター受け渡しも診断しやすくなります。SCM_RIGHTS配列に含まれる特定のファイルディスクリプターをLSM（Linux Security Module）が拒否した場合、SO_RIGHTS_NOTRUNCを使えば、受信側で拒否されたディスクリプターとerrnoを確認できます。最初の拒否で配列の残りまで失われる問題を避けるための改善です。

Linux 7.3はいつ利用できるのか

最初のLinux 7.3リリース候補版は2026年8月30日頃、安定版は通常の開発スケジュールが維持されれば10月下旬に登場すると予測されています。

ただし、安定版が公開された直後に、多くのサーバーやデスクトップへこれらの機能が届くとは限りません。各Linuxディストリビューションは、採用するカーネルを独自に選び、必要な変更をバックポートし、テストしたうえで別々のスケジュールで配布します。ローリングリリース型のディストリビューションは早く採用する可能性がありますが、固定リリース型ではさらに時間がかかることがあります。

Arch Linuxベースのローリング型ディストリビューションであるCachyOSは、早期採用候補のひとつと考えられます。しかし、2026年8月のリリース情報ではLinux 7.3の採用時期は確認されておらず、インストールイメージはLinux 7.1を使用していました。

インフラ運用者と開発者にとっての意味

インフラ運用者にとって、まず確認したいのはBIG TCPによるオーバーレイ経路の改善と、大量のネットワーク名前空間を同時に設定する際の競合緩和です。特に、VXLANやGeneve上で高スループット通信を行う環境、あるいは多数の名前空間を並行して作成・設定する環境では、実測する価値があります。

カーネル開発者にとっては、AIによるレビュー実験も重要な意味を持ちます。今回の動きが示しているのは、AIに開発全体を任せることではなく、反復的なトリアージや手続き上のフィードバックをモデルに担わせ、デッドロックや復旧処理の誤りにつながりかねない難しいケースはメンテナーが判断するという役割分担です。

Linux 7.3のネットワーク機能は大きく前進しますが、一般ユーザーが実際に利用できるようになるまでには、リリース候補版でのテスト、ハードウェア検証、ディストリビューション側の統合作業が残されています。