# パケット処理パイプラインのテーブル分割 ## 定義 パケット処理パイプラインのテーブル分割とは、パケット転送処理に必要な情報を単一のテーブルに集約して保持するか、複数のテーブルに分散して保持しIDで参照関係を結ぶかという設計判断を指す。パイプライン(Ingress/Egress Pipeline)は、条件を満たすパケットに一定の処理を行うルールを記録したマッチ・アクション・テーブル(ステージ)を順に並列実行する構造を持ち、各テーブルは「メタデータからキーを作成→テーブル検索→マッチしたアクションの実行→メタデータ更新→次テーブルの判断→メタデータを次テーブルへ渡す」というサイクルを繰り返す。同じ機能でもテーブル数やキーの取り方により、保持可能なルール数・更新速度・転送遅延への影響が変わる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]] ch.9 §9.2.1) ## 単一テーブル対複数テーブルのトレードオフ レイヤー3転送(ルーティング)処理を例に取ると、理論上は宛先IPプレフィックス・送信先インターフェース・宛先/送信元MACアドレスをすべて1つのテーブルに詰め込めば1回の参照で処理できる。しかし実際には、宛先IPプレフィックスの数に比べてNext Hopや宛先MACアドレス(Next Hop)の種類数は限られているという非対称性があり、情報を種類毎に複数のテーブル(Route・Next Hop・Neighbor・Router Interface)に分けIDで参照する設計のほうが、以下の利点を持つ。 - **メモリ効率**: 共有される情報(Next Hop・MACアドレス等)をIDで参照することで重複を避け、より多くの転送エントリを保持できる。 - **負荷分散(ECMP)**: 宛先IPプレフィックスに対して複数のNext Hopを用意し、パケット毎に異なるアルゴリズムでNext Hopを選択できる。 - **Next Hopの種類毎の拡張性**: トンネル(トンネルIDが必要)のようにNext Hopの種類によって異なる付随情報を保持できる。 - **更新の局所化**: 経路更新やリンクUp/Down時に変更が必要なエントリを最小限にし、更新時間の短縮とパケットロスの抑制につながる。 テーブルをどのような粒度で構成するかはSwitch ASIC毎に異なり、エントリ数・処理遅延・更新速度のうちどれを優先するかというターゲットユースケースに応じたアーキテクチャ選択になる。[[SAI (Switch Abstraction Interface)]]はこの粒度の違いを共通のSAIオブジェクト(Route Entry・Next Hop・Neighbor Entry・Router Interface)として抽象化するが、ASIC内部の実際のテーブル構成そのものはASIC毎に異なる。(Source: ch.9 §9.2.3) ## オブジェクトの参照順序と作成順序の逆転 パイプラインにおけるテーブルの参照順序(Route→Next Hop→Neighbor/Router Interface、パケット処理の実行順)と、SAIオブジェクトの作成順序(Router Interface→Neighbor→Next Hop→Route Entry)は逆になる。これは、後から作成するオブジェクトが先に作成されたオブジェクトのIDを属性として参照する(Next HopがRouter InterfaceのIDを持ち、Route EntryがNext HopのIDを持つ)ためであり、参照先のオブジェクトが存在しない状態でそのIDを属性に設定することはできないという依存関係の制約による。同型の構造はレイヤー2のブリッジ設定(VLAN作成→Bridge Port作成→Bridge PortをVLANのメンバーに追加)にも現れ、「参照されるオブジェクトを先に作る」という一般則としてSAIオブジェクトの作成順序全体を貫いている。(Source: ch.9 §9.2.2, §9.2.3) ## 横断的知見 - **SAIのパイプライン記述はP4/PISAのMatch-Action Unit記述と同じ「マッチ・アクション・テーブルの列」という語彙を共有するが、物理メモリ技術(TCAM/SRAM)への言及を持たない点で抽象化の階層が異なる**: [[プログラマブルデータプレーン]] conceptが扱う*Software-Defined Networks: A Systems Approach*第4章は、PISA(Protocol Independent Switching Architecture)のMatch-Action Unitを「SRAM/TCAMベースのメモリで照合し、ALUでアクションを実行する」ものと具体的に説明し、TCAMがワイルドカードマッチを可能にする一方SRAMより高価・高消費電力であるため可能な限り避けるべきという物理制約にまで踏み込む。これに対し『実践SONiC入門』第9章のSAIパイプライン説明(マッチ・アクション・テーブルの列、メタデータの受け渡し)は、同じ「テーブルを順に実行する」構造を語りながら、テーブルが物理的に何のメモリ技術で実装されるかには一切言及しない。SAIはP4コンパイラのように物理的なMatch-Action Unitへの割り当てを担わず、あくまでSAIオブジェクトという論理的な単位までしか抽象化しない——両者は同じパイプラインの語彙を共有しつつ、SAIはハードウェア設定APIとして、P4/PISAはコンパイラのターゲットアーキテクチャとして、異なる抽象化の層に位置づけられる。(Source: ch.9 §9.2.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.2) - **単一テーブル対複数テーブルというテーブル分割の判断基準(ch.9 §9.2.3)は、プログラマブルデータプレーンconceptが扱う「オープン対クローズド」という対立軸(*Software-Defined Networks: A Systems Approach* ch.5 §5.3)とは独立した、もう1つの設計トレードオフ軸である**: P4の議論はパイプラインの記述可能性(誰が変更できるか)に焦点を当てるのに対し、テーブル分割の議論はパイプラインが固定であることを前提に、その内部でメモリ効率・更新速度・拡張性をどう配分するかという問題を扱う。両者は独立した軸であり、プログラム可能なパイプライン(P4)でもテーブル分割の判断(単一テーブルか複数テーブルか)は同様に必要になるはずだが、[[プログラマブルデータプレーン]] conceptが依拠するソースはこの点(P4プログラム内でのテーブル分割設計)に触れていない。(Source: ch.9 §9.2.3, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.3) ## 未解決の問い - 本書は「テーブル粒度はSwitch ASIC毎に異なる」と述べるにとどまり、実際のASIC(Broadcom Trident/Tomahawk、Intel Tofino等)がRoute/Next Hop/Neighbor/Router Interfaceを何段の物理テーブルに実装しているかの実例は示さない。[[プログラマブルデータプレーン]] conceptが扱うPISAのMatch-Action Unit数(段数)との対応関係は今後の突き合わせ課題。 - 複数テーブル化がもたらすメモリ効率化(Next Hopの共有)とECMP負荷分散は同じ設計から派生する副産物として語られるが、この2つの利点はテーブル分割の必要条件か十分条件か、本書の記述からは切り分けられない。 - SAIオブジェクトとしての抽象化(ROUTE_ENTRY→NEXT_HOP→NEIGHBOR_ENTRY/ROUTER_INTERFACE)は、ASIC内部が実際に同じ段数のテーブル構成を持つことを保証しない。SAIオブジェクトグラフと物理ハードウェアのテーブル構成がどこまで一致するか(あるいは意図的に一致させない抽象化なのか)は本書からは読み取れない。 - P4/PISAベースのパイプラインでも、SAIと同種のテーブル分割トレードオフ(単一テーブル対複数テーブル、正規化によるメモリ効率化)が明示的に議論されている一次資料はまだ突き合わせていない。 ## 関連 - 概念: [[プログラマブルデータプレーン]] / [[抽象化(ソフトウェア設計)]] - 実体: [[SAI (Switch Abstraction Interface)]] - ソース: [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第9章 §9.2.1〜§9.2.3.