# ホストネットワークスタック性能 ## 定義 ホストネットワークスタック性能は、NIC からアプリケーションまでのパケット処理経路が、CPU サイクル、メモリ帯域、キャッシュ容量、NUMA 配置、スケジューリング、プロトコル処理をどのように消費するかを扱う性能領域である。 100 Gbps 級のリンクでは、ネットワークコアよりもホスト側がボトルネックになり、単純な TCP/IP 処理削減だけでなくデータ移動とホスト資源の配分が支配的になる。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) ## 主要なボトルネック - **データコピー**: 単一の長フローでも、受信側のカーネルバッファからアプリケーションバッファへのコピーが CPU サイクルの約 49%を占める。 - **DCA とキャッシュ容量**: 帯域遅延積が DCA で利用できる L3 キャッシュ容量を上回ると、アプリケーションがコピーする前に後続 DMA がデータを追い出す。 - **NUMA 非局所性**: NIC リモート NUMA でアプリケーションを動かすと、キャッシュミス増加とスループット毎コア約 20%低下が生じる。 - **フロー多重化**: 複数フローが同じ L3 キャッシュを競合し、受信側のデータコピーコストを増やす。 - **集約機会の減少**: all-to-all のようにフロー数が増えると GRO が大きな `skb` を作れず、TCP/IP の 1 バイトあたり処理コストが増える。 - **スケジューリング**: ネットワーク飽和時のアプリケーションスレッドの待機・再開と、短フローの頻繁なイベント処理が CPU を消費する。 - **IOMMU のページ管理**: DMA 用ページのマッピング・アンマップがメモリ管理オーバーヘッドを増やす。 - **CPU 資源管理**: 短い RPC のテールでは、softIRQ の誤計上、runtime 公平性、NIC 割り込み調整がパケット処理自体より大きな待ち時間を生む。 ## 測定の観点 同じスタックでも、単一フロー、one-to-one、incast、outcast、all-to-all の通信パターンで CPU 効率が変わる。 また、長フローはデータコピー、短フローは TCP/IP 処理とスケジューリングという異なる支配要因を持つため、フローサイズの分布と同居関係を測定条件に含める必要がある。 [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]] は、スループット毎コア、送受信 CPU 使用率、CPU サイクル分類、L3 キャッシュミス率、NAPI からコピー開始までの遅延を組み合わせてこの分解を行った。 ## 横断的知見 - **高帯域化はボトルネックをプロトコル処理からデータ移動へ移す**: 2012 年の [[netmap]] はパケット単位のシステムコール・動的確保・カーネル／ユーザー空間コピーを削減し、10 Gbps のパケット I/O を線速化した。一方、100 Gbps の Linux TCP/IP スタックでは、TSO/GRO でパケット単位処理を抑えた後に、受信側のデータコピーが最大の消費要因として残る。線速化の次の課題が per-packet 処理から per-byte データ移動へ移ったことを示す。(Source: [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) - **ゼロコピーは処理経路の選択と組み合わせて評価する必要がある**: [[iip]] はゼロコピー I/O と NIC オフロードを API 境界に組み込むが、小メッセージでは scatter-gather 無効化がわずかに有利になる場合も報告する。本稿でも長フローではデータコピーが支配的だが、4 KB の短フローでは TCP/IP 処理とスケジューリングの比率が上がる。コピー回数だけでなく、メッセージサイズ、集約機会、CPU キャッシュ、API オーバーヘッドを同時に測る必要がある。(Source: [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) - **カーネル外へ処理を移してもホスト資源の問題は消えない**: [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems|mTCP]] や [[カーネルバイパスネットワーキング]] はシステムコール・共有データ構造・パケット単位処理を削減できるが、本稿が示す NUMA 配置、キャッシュ競合、長短フローの混在、アプリケーションとネットワークのスケジューリング協調は別の設計問題として残る。スタックの場所を変えることと、ホスト資源を効率よく配分することは同じ最適化ではない。(Source: [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) - **統合境界の設計は測定されたボトルネックから導かれる**: [[iip]] は処理ループ、CPU コア割り当て、NIC オフロード、パケット管理を統合側へ委ねる。本稿の長短フロー混在と NUMA 実験は、固定的な処理パイプラインとネットワーク非認識型 CPU スケジューラが性能制約になることを示しており、iip の責任境界を別の実験系から裏づける。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]]) - **同じホストスタックでも、平均 CPU コストとテールレイテンシの支配要因はワークロードで変わる**: 100 Gbps の長フローでは受信側データコピーが約 49%を占めるのに対し、64 バイト RPC の競合時は `rx_sched` が支配的になる。ホストネットワークスタックを評価するには、スループット毎コアだけでなく、要求単位のテール、接続数、in-flight 数を同時に測る必要がある。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **ネットワークスタックの高速化は、パケット経路の短縮からホスト資源の公平性へ拡張される**: netmap、mTCP、iip はコピー、システムコール、共有処理、実行ループの責任境界を変えるが、本稿は成熟した Linux スタックでも CPU スケジューラと NIC の相互作用を調整すればユーザー空間スタックに近い性能を得られることを示す。スタックを移動する設計と、スタックを適切にスケジュールする設計は補完関係にある。(Source: [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]], [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **TASは共通ケースの分離、Linuxの後続研究は資源管理の修正で同じ問題空間へ入る**: TASは短RPCのTCP処理をfast pathへ分離し、mTCP・iipとは異なる安全性と互換性の境界を作る。一方、LinuxのsoftIRQ計上、公平性、割り込み調整を修正する研究は、スタックを移動しなくても競合時のテールを下げる。高帯域のデータコピー、短RPCのパケット処理、競合時のスケジューリングは、単一の高速化手法ではなくワークロード別に組み合わせるべき軸である。(Source: [[@2019__EuroSys__TAS - TCP Acceleration as an OS Service]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **短命接続では、平均的なパケット処理量より共有状態の局所性が先にボトルネックになる**: Fastsocket は global TCB table、VFS の inode・dentry、共有 accept queue のロック競合を、Local Listen Table・Local Established Table・RFD・ソケット専用 VFS 経路で分割した。2021 年の長フロー測定が示す per-byte データ移動の支配性とは対象ワークロードが異なるが、どちらも NIC からアプリケーションまでのホスト経路全体を測定単位にする必要性を示す。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) - **接続局所性と CPU 資源公平性は補完関係にある**: Fastsocket は一つの接続を一つのコアへ固定してキャッシュバウンスとロック競合を減らすが、固定先のコアが過負荷になると負荷の偏りを生む。2026 年の要求数ベース公平性・softIRQ 計上・割り込み調整の研究は、局所性を保ったままコア間の進捗をどう公平にするかという次の問題を明示する。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]], [[TCP接続局所性]]) - **ホストスタックの「処理オーバーヘッド」と「輻輳」は異なる現象だが、同じNIC-CPU/メモリ経路上で相互作用する**: 本concept が扱う[[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]等は、データコピー・NUMA配置・スケジューリングといった「処理に要するCPUサイクル」を測定するのに対し、[[ホスト輻輳制御]]([[@2023__SIGCOMM__Host Congestion Control]])はPCIe・IIO・メモリコントローラ間のクレジットベースフロー制御が引き起こす「キューイングとパケットドロップ」という別種の現象を扱う。前者はCPUが処理し切れないことによる遅延、後者はロスレスインターコネクトが輸送し切れないことによる輻輳であり、いずれもホストネットワークという同じ物理経路上で発生するが原因(計算資源 vs インターコネクト帯域)が異なる。100 Gbps超のホストで両者がどう複合するかは、本concept と[[ホスト輻輳制御]]の双方で未検証の領域として残る。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2023__SIGCOMM__Host Congestion Control]]) - **NUMA非局所性による性能低下は、2021年のデータコピー分析より14年早く、しかもNIC-プロセッサ間の帯域幅そのもので実測されていた**。[[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]は現代のNICでNUMAリモート配置がスループット毎コア約20%低下を招くと報告するが、[[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]]はAMD OPTERON/HYPERTRANSPORT世代のInfiniBand・Myri-10Gで、DMA/RDMA書き込みのNUMA非局所性による帯域低下が最大24〜40%に達すること、かつその効果が書き込み方向にのみ非対称に現れることを既に発見していた。ホストネットワークスタックのNUMA配置問題は新しい現象ではなく、インタコネクト技術(HYPERTRANSPORT→現代のNIC/PCIe)を超えて繰り返し観測される構造的な性質だと言える。(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) ## 未解決の問い - [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]]が発見したRDMA/DMA書き込みのみに現れる非対称NUMA効果は、[[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]が測定する現代の100Gbpsスタックの受信側データコピーにも同様の書き込み/読み取り非対称性として現れるか。両ソースとも読み書き別のCPUサイクル・帯域内訳を直接比較できる形では報告していない。 - ホスト輻輳(IIOバッファ占有量の飽和によるPCIeスループット低下)が発生している状況で、受信側データコピーのCPUオーバーヘッドはどう変化するか。ホスト輻輳制御(hostCC)とホストスタック処理オーバーヘッド削減(ゼロコピー等)を同時に適用した場合の相互作用は測定されていない。([[ホスト輻輳制御]]、[[@2023__SIGCOMM__Host Congestion Control]]) - Linux の現行カーネル、最新 NIC、CXL や DPU を含む構成で、受信側データコピーと DCA キャッシュミスは依然として支配的か。 - Linux の現行カーネルと最新 NIC で、長フローのデータコピーと短 RPC の `rx_sched` を一つのワークロードモデルで予測できるか。 - `MSG_ZEROCOPY`、TCP 受信 `mmap`、AF_XDP、io_uring を同一の長短フロー混在ワークロードで比較したとき、アプリケーション変更コストを含む最適点はどこか。 - 長フローを NIC ローカル NUMA、短フローをリモート NUMA へ配置するネットワーク認識型スケジューラは、負荷変動と移動コストを含めて有効か。 - 受信側主導トランスポートは、TCP の送信側主導性が生む受信コアのフロー競合をどこまで制御できるか。 - GRO や TSO の集約単位をフローサイズ分布に適応させると、all-to-all の `skb` 分散と TCP/IP 処理オーバーヘッドをどの程度削減できるか。 - CPU サイクル、メモリ帯域、キャッシュミス、電力、末尾レイテンシーを一つの評価指標へ統合するには、どのコストモデルが妥当か。 - 要求数ベースの公平性単位と、受信側ゼロコピー、NUMA 局所性、NIC オフロードを同時に適用したときの資源配分モデルはどうあるべきか。 ## 関連 - [[ゼロコピーネットワーキング]] — カーネル・ユーザー空間間のコピーを削減する手法群。 - [[カーネルバイパスネットワーキング]] — カーネルネットワークスタックを部分的・完全に迂回する設計。 - [[ユーザーレベルTCPスタック]] — TCP/IP 処理をユーザー空間へ移す実装系譜。 - [[TCP IPスタック統合|TCP/IPスタック統合]] — スタックと CPU、NIC、メモリ、実行ループの責任境界を設計する問題。 - [[アプリケーション並行実行モデル]] — フロー混在とスケジューリングオーバーヘッドを分析する関連概念。 - [[レイテンシ分析]] — NAPI、TCP/IP、データコピーなど処理区間を分解する方法論。 - [[ネットワークワークロードのCPUスケジューリング]] — softIRQ、runtime、公平性単位、DIM をネットワーク処理に合わせる設計。 - [[TCP接続局所性]] — TCP 状態、受信パケット、アプリケーションを同じ CPU コアへ固定する設計。 - [[NUMAメモリ配置]] — NUMAハードウェアモデルとメモリ配置一般の基礎概念。 ## 出典 - [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]] - [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]] - [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]] - [[@2024__SIGCOMM CCR__iip - An Integratable TCP IP Stack]] - [[@2026__SIGCOMM__Understanding Host Network Stack Latency]] - [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]](§3〜4、NUMA配置がNIC通信のレイテンシ・帯域幅に与える非対称な影響)