Linux mainlineは2026年8月20日、net-next-7.3を取り込んだ。中心にあるのは、経路制御ルールの更新で大域的なロックであるRTNLへの依存を減らす変更と、BIG TCPをVXLAN、GeneveというUDPトンネルへ広げる変更である。前者は多数のnetwork namespaceを同時に操作する場面、後者はオーバーレイ経由のデータパスを対象にする。Linux 7.3の正式版はまだ公開されておらず、これはマージウィンドウ段階でmainlineに入ったコードである。性能値を読む際は、どのロックを外したのか、どのトンネルと設定で測ったのかを分ける必要がある。
4,096個のnamespaceでFIB更新を並列化
FIB（Forwarding Information Base）ルールのRTM_NEWRULEとRTM_DELRULEは、各fib_rules_opsが持つmutexで守る構造へ移った。従来は、独立したnetwork namespaceのルール操作も、ネットワークデバイス設定を広く保護するRTNLの下で直列化され得た。今回の変更後も、最初のIPv4ルールでfib_unmerge()を実行する場合にはRTNLが必要である。一律にRTNLをなくしたわけではない。
変更を送った開発者は、4,096個のnetwork namespaceを作り、それぞれへ1,024個のルールを並列に投入する合成試験を示した。IPv4の実時間は22.752秒から0.918秒となり、計算上は24.8倍である。IPv6は35.181秒から1.214秒へ短縮し、29.0倍だった。シリーズの説明では概数としてIPv4を20倍、IPv6を30倍としている。
この試験が捉えたのは、大量の独立namespaceが同じ大域的なロックを待つ負荷である。一般的なコンテナ起動が同じく25〜29倍速くなることは示していない。それでも、namespaceごとに独立して扱えるルール操作を、RTNLで不必要に直列化しにくくするという機構の変更は明確だ。
VXLANとGeneveへ広がるBIG TCP
BIG TCPは、ネットワークスタック内部で64KiBを超えるまとまりを扱い、送信前にGeneric Segmentation Offload（GSO）やTCP Segmentation Offload（TSO）で送信可能なセグメントへ分割する仕組みである。物理ネットワーク上に巨大パケットをそのまま流す機能ではない。これまではCilium利用時、BIG TCPの経路は直接ルーティングに限られていたが、今回の更新でUDPオーバーレイであるVXLANとGeneveでも64KiB超のTSO/GRO経路を使えるようになる。
VXLANとGeneveの変更は、いずれも作者環境でnetperf TCP_STREAMを測った。VXLANにはhardware tunnel offloadをすべて無効にした別条件もある。
| トンネルと条件 | 変更前 | 変更後 | 計算上の差 |
|---|---|---|---|
| VXLAN、標準MTU | 34,440.00 Mbit/s | 39,564.78 Mbit/s | +14.9% |
| VXLAN、8k MTU | 55,684.26 Mbit/s | 61,466.47 Mbit/s | +10.4% |
| VXLAN、ハードウェアのトンネルoffload無効 | 21,820.82 Mbit/s | 29,390.78 Mbit/s | +34.7% |
| Geneve、標準MTU | 37,391.34 Mbit/s | 40,891.57 Mbit/s | +9.4% |
| Geneve、8k MTU | 58,030.19 Mbit/s | 61,458.39 Mbit/s | +5.9% |
表の差は、Linux 7.3全体の性能向上率ではない。BIG TCPを使うには管理者がgso_max_sizeやgro_max_sizeなどを適切に設定し、経路全体が対応する必要がある。NICやtunnel offload、MTU、トラフィックパターンでも結果は変わるため、実務では利用するCNIとNICの組み合わせで確かめることになる。
速度とは別に変わる復旧とエラー通知
MPTCP（Multipath TCP）には、極端なメモリ圧迫下でout-of-order queueを最後の手段としてpruneする変更が入った。対象はMPTCP層のキューであり、再送と回復を速めるための処置である。通常時のスループットを示す更新ではなく、メモリが厳しい状態で回復へ移る経路を持たせる変更として読むべきだ。
AF_UNIXのSCM_RIGHTS受信にも、失敗の伝え方を変える更新が加わった。Linux Security Modules（LSM）が一部のファイル記述子を拒否したとき、SO_RIGHTS_NOTRUNCを有効にすると、配列を最初の拒否位置で切らない。各スロットを残したまま拒否された場所へLSMのerrnoを置けるため、受信側はどのファイル記述子が拒否されたかを扱える。
BIG TCPのような高速経路と違い、これらの変更は異常時のふるまいを対象にする。メモリ圧迫時にどのキューを捨てるか、LSM拒否を受信側へどう返すかを明示し、回復やエラー処理で失われる情報を減らす。
mm81xが開くWi-Fi HaLowのmainline入口
Morse Microのmm81x向けWi-Fi HaLowドライバもmainlineに入った。USBとSDIOをサポートし、sub-1GHzのIEEE 802.11ah系であるWi-Fi HaLowを、長距離・低消費電力のIoT用途へ使う際の入口になる。ベンダー固有のツリー外モジュールへの依存を減らせる。
ただし、初期実装はステーション、アクセスポイントと基本機能に絞られている。地域対応も限定されており、Wi-Fi HaLowの全機能、全地域、全製品ですぐ利用できる状態ではない。同じ更新束にはnxpwifiの新規ドライバ、AMD/Solarflare NIC向けCXL対応の初期実装、Intel iXDとZTE Dinghaiのドライバ骨格も含まれる。対応範囲をmainlineへ広げながら、初期段階であることを明示した更新である。
Linux 7.2のネットワーク更新はWi-Fi AwareやUHR、RTL8159など、端末や規格、デバイス対応が中心だった。7.3の束では、オーバーレイのデータパスと制御面の並列性、さらに異常時の処理へ重心が移っている。
なぜ複数のLLMでパッチを検査するのか
Jakub Kicinskiは、Paolo Abeniと自身がnetで632件、net-nextで648件のパッチを取り込んだ概算を示した。netは現行リリースに向けた修正、net-nextは将来のリリースに向けた新規コードを集めるツリーである。この二つの数字は、mainlineのmerge tagに含まれるcommit総数と同じ分母ではない。
Kicinskiは、net-nextの3分の1から2分の1が、AI由来に見える低優先度の修正、整理、説明改善だとも見積もった。監査済みの計数ではなく、AI由来のパッチ全体を一律に評価する数字ではない。
メンテナーチームはMetaの支援により、各パッチを複数の最先端モデルで検査する利用枠を確保した。一方でKicinskiは、PCIeエラーやタイムアウトのように発生頻度が低い事象では、競合状態を含むAPIの問題をLLMだけでは解けないとも述べている。次の周期では、patchworkの管理、定型的な手続き上の指摘、commit messageの編集といった作業をLLMへ移す方針である。
7.3-rc1以降は、BIG TCPのトンネル経路がCNIとNICごとにどう検証されるか、FIB変更が並列環境で回帰しないかに加え、発生頻度の低いエラー経路を人間のレビューでどう扱うかが実装の定着を左右する。
