カーネルのパケット受信経路：NAPI と割り込み緩和

毎パケット割り込みはなぜ破綻するのか

NICがパケットを受け取ると、まずそのデータをホストメモリの 受信リングバッファ へ DMA で書き込み、続いてCPUへ 割り込み（ハードウェア割り込み, ハードIRQ） を上げて「パケットが届いた」と知らせます。素朴な設計では1パケットごとに1割り込みです。低負荷ならこれで何の問題もありません。

ところが回線が10Gbps級になり、毎秒数百万パケットが届く状況を考えてください。割り込みは現在実行中の処理を強制的に中断させる重い操作で、コンテキスト保存・割り込みハンドラ起動・復帰のコストが毎回かかります。割り込み頻度が高すぎると、CPUは割り込み処理だけで時間を使い果たし、肝心のパケット本体を処理する余力がなくなります。最悪の場合、割り込み処理に追われてアプリもカーネルのプロトコル処理も前進できなくなる receive livelock（受信ライブロック） に陥ります。これが 割り込みストーム の害です。

NAPI：割り込みを止めてポーリングへ切り替える

この問題を解くのが NAPI（New API） です。発想は単純で、負荷が高いときは割り込みをやめてポーリングに切り替える というものです。

動作はこうです。最初のパケットでNICが割り込みを上げると、ドライバのハードIRQハンドラは(1)このデバイスの 受信割り込みを一旦マスク（無効化） し、(2)NAPIのポーリングを スケジュール するだけで即座に返ります。以降カーネルは割り込みを待たず、ドライバの poll() 関数を呼んでリングバッファに溜まったパケットを まとめて刈り取り（poll） ます。リングが空になったらポーリングを終了し、再び割り込みを有効化して低負荷モードへ戻ります。

低負荷: 割り込み駆動（パケットごとに割り込み、レイテンシ最小）
   │  パケット殺到で割り込み発生
   ▼
高負荷: 割り込みマスク → poll でまとめ刈り取り（割り込み回数を抑制）
   │  リングが空 = 負荷が引いた
   ▼
低負荷へ復帰: 割り込み再有効化

要点は 負荷適応 であること。低負荷ではパケットごとに割り込みが上がり遅延が小さく、高負荷では割り込みを止めて1回のポーリングで何百パケットもまとめて処理するため、割り込み回数がパケット数から切り離されます。「割り込みとポーリングのいいとこ取り」を負荷に応じ自動で行う仕組みです。

ハードIRQとソフトIRQ：処理の二段分割

NAPIを理解する鍵は、受信処理が 2つのフェーズに分割 されている点です。割り込みハンドラ（ハードIRQ）の中では割り込みが禁止されており、ここに重い処理を書くと他の割り込みを長く塞いでしまいます。そこでLinuxは「すぐ済む最小限」と「重いが急がない本体」を分けます。

• ハードIRQ（top half）: 割り込み禁止コンテキストで走る。やることは最小限——割り込みをマスクしてNAPIポーリングをスケジュールし、即返る。
• ソフトIRQ（bottom half, NET_RX_SOFTIRQ）: 割り込みを許可した状態で走る遅延処理。ここで poll() を回し、リングからパケットを取り出してプロトコルスタック（IP・TCP/UDP）へ流し込む重い処理を行う。

ソフトIRQは割り込み復帰時などに実行されますが、ソフトIRQ処理が長引いてCPUを占有し続けないよう、1回の処理には 予算（budget） という上限が設けられています。poll() が1度に刈り取れるパケット数の上限（weight）と、ソフトIRQ全体で処理できる総量（netdev_budget と時間）です。予算を使い切ってもまだパケットが残っていれば、ソフトIRQはそこで中断し、ksoftirqd というカーネルスレッドへ処理を委ねます。

ハードIRQ: NAPIをスケジュール（割り込み禁止・最小限）
   │
   ▼
ソフトIRQ NET_RX: poll() で budget 件まで刈り取り → スタックへ
   │  budget を超えてもまだ残っている
   ▼
ksoftirqd: 残りを通常スレッドとして処理（他タスクと公平にスケジュール）

リングバッファ：NICとカーネルの受け渡し場所

受信リングバッファ（RX ring）は、NICとカーネルがパケットを受け渡す 固定長の環状ディスクリプタ配列 です。各エントリは、DMAで書き込む先のメモリ（受信バッファ）を指すディスクリプタです。

仕組みは生産者・消費者モデルです。NICが空きディスクリプタの指すバッファへパケットをDMAで書き込んで進める側（生産者）、カーネルが poll() でパケットを取り出し、新しい空きバッファを補充して進める側（消費者）です。両者は別々のポインタ（head/tail）で環を周回します。

ここで重要なのが オーバーフロー です。トラフィックが届くペースにカーネルの刈り取りが追いつかないと、リングに空きディスクリプタがなくなり、以降に届いたパケットはNICが ドロップ します。これが ethtool -S で見える rx_dropped / rx_no_buffer の正体です。

リングを大きくすればバースト耐性は上がりますが、滞留時間（遅延）が伸び、根本的に処理が追いつかないなら溢れは止まりません。リング拡大は「瞬間的なバーストの吸収」には効いても、「定常的な処理能力不足」の解にはならない、と切り分けるのが肝心です。ユーザー空間への往復コピーを削る話は ソケットバッファとゼロコピー送受信 で、カーネルそのものを外す究極形は RDMA と RoCE：カーネルバイパス転送の原理 で扱っています。

RPS と RFS：受信処理を複数コアへ分散する

ここまでで「割り込みは抑えた」「重い処理はソフトIRQへ回した」状態ですが、もう一つの壁があります。ソフトIRQは割り込みを受けたコアで走る ため、1つのキューしか持たないNICでは受信処理が 単一コアに集中 し、そのコアが100%になって他コアが遊ぶ、という偏りが起きます。

これを分散する仕組みが3層あります。まずハードウェアの RSS（Receive Side Scaling） で、NICが複数の受信キューを持ち、パケットの5タプル（送信元/宛先IP・ポート・プロトコル）の ハッシュ で振り分け、キューごとに別コアへ割り込みを上げます。NICが複数キュー対応ならこれが一次分散です。フローのハッシュで経路や処理先を分ける一般原理は ECMP とフローハッシュによる負荷分散 と同じ考え方です。

RSSが使えない（単一キューNIC）場合や、さらにソフトで散らしたい場合に使うのが RPS（Receive Packet Steering） です。RPSはソフトIRQの中でパケットのハッシュを計算し、処理を 別コアのバックログキューへ転送 して、そのコアでプロトコル処理を行わせます。RSSのソフトウェア版で、5タプルのハッシュにより 同一フローは同じコア へ送られ、TCPのパケット順序が保たれます。

RPSの弱点は、ハッシュで決めた処理コアと、recvmsg() でデータを読むアプリが動いているコアが 一致するとは限らない 点です。受信処理をコアAで終えても、アプリがコアBにいれば、データがコア間を渡りCPUキャッシュのミスが増えます。これを直すのが RFS（Receive Flow Steering） です。RFSはフローごとに「直近どのコアのアプリが recvmsg() したか」を記録し、そのフローの受信処理を アプリと同じコア へ寄せます。受信処理・プロトコル処理・アプリ読み出しが同一コアに揃うことで、キャッシュ局所性が最大化され遅延が下がります。フローと処理先の対応はTCP/UDPの識別子に基づくため TCP と UDP の違い の5タプルが土台になります。

まとめ

NICは受信パケットをDMAでリングバッファに置き割り込みを上げますが、毎パケット割り込みは高pps時に割り込みストームを起こしCPUを飽和させ、receive livelockを招きます。NAPIは高負荷時に割り込みをマスクしてポーリングへ切り替え、1回のソフトIRQで複数パケットをまとめて刈り取ることで割り込み回数をパケット数から切り離します。処理はハードIRQ（最小限・NAPIスケジュールのみ）とソフトIRQ（NET_RXで予算上限まで処理、超過分はksoftirqd）に二段分割され、リングの溢れは刈り取りの遅れを意味します。そして単一コアへの集中はRSS（NICハード）・RPS（ソフトのコア分散）・RFS（アプリのコアへ寄せる）で散らす——割り込みを抑え、処理を遅延実行へ回し、複数コアへ広げる、という三段構えで高負荷の受信を支えるのがLinuxのパケット受信経路の全体像です。