Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
P4 ちょっと調べてみた
Search
Masaru OKI
March 20, 2018
Technology
4
2.8k
P4 ちょっと調べてみた
プログラマブルASICを中心に汎用なパケット処理プログラミングを提供するP4言語 (
https://p4.org/
) について、少し調べてみたことをまとめてみました。
Masaru OKI
March 20, 2018
Tweet
Share
More Decks by Masaru OKI
See All by Masaru OKI
SONiCを自前でビルドする話
imasaruoki
1
950
Ansible把握した 1日目
imasaruoki
0
270
NPLによるデータプレーンプログラミング
imasaruoki
8
2.3k
SONiC近況報告 2019/Fall
imasaruoki
1
1.2k
ホワイトボックススイッチをAnsibleで操る話
imasaruoki
2
2.3k
ホワイトボックススイッチとNOSを取り巻く状況について
imasaruoki
3
2.2k
SONICイントロダクション
imasaruoki
1
440
SONiCをはじめてみよう
imasaruoki
4
1.7k
SONiCで設定するFRRouting
imasaruoki
0
1.5k
Other Decks in Technology
See All in Technology
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
【令和最新版】AWS Direct Connectと愉快なGWたちのおさらい
minorun365
PRO
5
750
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
170
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
ドメイン名の終活について - JPAAWG 7th -
mikit
33
20k
TypeScript、上達の瞬間
sadnessojisan
46
13k
AGIについてChatGPTに聞いてみた
blueb
0
130
SSMRunbook作成の勘所_20241120
koichiotomo
2
130
元旅行会社の情シス部員が教えるおすすめなre:Inventへの行き方 / What is the most efficient way to re:Invent
naospon
2
340
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
280
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
100
Featured
See All Featured
What's new in Ruby 2.0
geeforr
343
31k
Statistics for Hackers
jakevdp
796
220k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
For a Future-Friendly Web
brad_frost
175
9.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
Happy Clients
brianwarren
98
6.7k
Facilitating Awesome Meetings
lara
50
6.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
How to Ace a Technical Interview
jacobian
276
23k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Transcript
P4 ちょっと調べてみた Mar 20, 2018 Masaru OKI @masaru0714
P4の前にASICの話 • ASIC - Application Specific Integrated Circuit 特定用途向け集積回路。 •
ネットワーク機器向けのASICは、ハードウェアでパケット処理する LSI。 • パケット転送やVLAN処理などはASICで。BGPなど複雑な処理はCPUで。 • CPUを使わずASICだけで処理すると高速。CPUを介すると低速。 CPU ASIC メモリ ストレージ PHY PHY PHY PHY 管理用NIC 設定、運用 ・ユーザートラフィック ・BGP, OSPF等
ASICは万能ではない • 集積回路を設計して試作、テスト、修正、試作、テストの繰り返し。 • 完成までに相当の時間とコストがかかる。数年、数億円。 • かかわる人数も大きい。数人でできるものではない。 • 大量に長期供給することによってコストを回収する。 •
設計変更は簡単ではない。ソフトウェアのような感覚では変更できない。 • つまり設計段階で盛り込んだ機能以外のことはできない。 カスタムデータプレーンを実現するには通常の ASICでは力不足
プログラマブルなパケット処理ハードウェア • FPGA - Field Programmable Gate Array ◦ 外部から回路情報を流し込んで回路を作れる
LSI。試作や少量生産向け。 ◦ FPGA自体はとくにネットワーク向けに特化というわけではない。 ◦ FPGAを搭載したNICがある。 • Smart NIC ◦ 定義があいまい だが、ここではCPUを介さず複雑な処理ができる NICの総称とする。 ◦ FPGA内蔵NIC、ARM内蔵NIC、NPU搭載NIC、あるいは単に多機能な NIC。 ◦ 基本的にPCやサーバに取り付けて使う。 ◦ 価格はピンキリ。 • プログラマブルASIC ◦ ネットワーク向け ASICであるが、機能を外部からプログラミングできる製品。 ◦ パケット処理ロジック (ヘッダフィールドの値が xxだったら書き換る、等 )を記述可能。 ◦ ソフトウェア開発のように設計変更が可能。 ◦ プログラマブルASICを採用したネットワークスイッチ製品がある。
プログラマブル、何が嬉しい? • 典型的なパケット処理(L2,L3,ACL,QoS)でいいなら、従来の製品でいい。 • 多機能なものは高価格になるし使わない機能もあってコスト効率が悪い。 ◦ ある特殊な機能だけ使いたいときに、他の機能を含めたお金を払うことに。 →従来のASICでは、処理できないパケットはどうやったって処理できない。 • 新しいトンネルプロトコルに対応できない
(数年前のVXLANのような状況)。 ◦ 最近で言えば、例えば SRv6 • CPU回しにすれば、一応、処理できるが、遅くて実用にならない。 • 特殊なアクションは実行できない。 CPU回しにすれば(以下同文) プログラマブルなら、処理を書き足せば、すぐ対応できる!
どうやってプログラムを入れる? • それぞれの製品ごとに用意されている手段で書き込む。 互換性はない。 ◦ ツールで書き込む、アプリケーション起動時に書き込む、等。 ◦ 書き込み専用の USB接続が別途必要なハードウェアもある。 •
エンドユーザができるのは、 (できたとして)何を書き込むかを選ぶ程度。 CPU ASIC メモリ ストレージ PHY PHY PHY PHY 管理用NIC
プログラム開発の手段 • FPGA: OpenCL等で記述して(HDL中間出力を介して)回路データに変換 • FPGA: VerilogなどのHDL(ハードウェア記述言語)を直接書いて変換 • Smart NIC:
製品ごとのSDKを用いて(主にC/C++言語で記述して)コンパイル • プログラマブルASIC: 製品ごとのSDKを用いて(同上)コンパイル 問題点 • ターゲットが変わるたびに一から学習する必要がある • 成果物の、ターゲット間の再利用ができない • 特定ベンダーの特定製品に依存することになる • 技術情報を共有できない(SDKがNDAベースで提供されるため) • 成果物をオープンにできない
ターゲット非依存の開発手段: P4 https://p4.org/ • P4 is a high-level language for
programming network switches. • 命名由来: Programming Protocol-Independent Packet Processors • ネットワークスイッチをプログラムするための高級言語。 • プロトコル非依存、ターゲット非依存。 • FPGA、Smart NIC、プログラマブルASIC、ソフトウェアの実装がある。 • 代表的な対応製品はBarefoot Tofino (プログラマブルASIC)。 • https://github.com/p4lang で仕様書やサンプルコードなど公開中。 • P4 Language Consosiumは2018年3月、ONFとLinux Foundationに加入。
P4を使ったデータプレーン開発と、その設定 P4で定義できるもの • parser • match field • action •
table • pipeline テーブルへのエントリ設定方法は各自で用意。 OpenFlowのmatchやaction, pipelineの仕様を自分で定義 できる(自分で作らないといけ ない) OpenFlow Protocolのような標 準の設定プロトコルはないので 製品ごとに違う
P4でデータプレーンをプログラムする • ソースは共通(例外あり)。 • コンパイラはターゲット別。 • バイナリも。 • ASICへの投入も別(でした)。 •
設定も別。 CPU ASIC メモリ ストレージ PHY PHY PHY PHY 管理用NIC P4ソースコー ド P4 コンパイラ ターゲット用 バイナリ
P4でデータプレーンをプログラムする(PIを使用) • ソースは共通(例外あり)。 • コンパイラはターゲット別。 • バイナリも。 • ASICへの投入は共通! •
設定も共通! CPU ASIC メモリ ストレージ PHY PHY PHY PHY 管理用NIC P4ソースコー ド P4 コンパイラ ターゲット用 バイナリ
• P4Runtime Protocolを使い設定を投入する • バイナリ投入も • CLIも用意される • https://github.com/p4lang/PI ◦
Protocol Independent APIの略 • 普及はこれから? switch PI (P4Runtime) ASIC OS (driver) P4Runtime gRPC server P4Runtime Controller C言語で用意されたライブラリ を呼び出して作成する (あるいはベンダが提供する ) P4Runtime Protocol アプリケーション フロントエンド P4ソー スコー ド P4 コンパイ ラ ターゲット用 バイナリ
すぐ試せるソフトウェア実装: bmv2 https://github.com/p4lang/behavioral-model • bmはBehaviorial Modelの略。 • bmをターゲットにしたP4コンパイラはP4を入力とし、JSONを出力する。 • bmv2はJSONを読み込んで、P4で書かれたとおりの振る舞いを実行する。
• 実用的な速度では動作しないので機能検証用。 他のソフトウェア実装 • P4@ELTE/p4c DPDKを使うバイナリを出力する P4コンパイラ • BMAcc (リンク先はPDF) DPDKを使ってBMv2を高速化したという発表 • PISCES P4によるカスタマイズが可能な OVSベースのソフトウェアスイッチ
P4-14とP4-16の二つの仕様 P4-14 header_type ethernet_t { fields { dstAddr : 48;
srcAddr : 48; etherType : 16; } } add_to_field(ipv4.ttl, -1) P4-16 typedef bit<48> macAddr_t; header ethernet_t { macAddr_t dstAddr; macAddr_t srcAddr; bit<16> etherType; } modify_field(ipv4.ttl, ipv4.ttl - 1) 書式が全然違っていて互換性がない! P4対応を謳っている製品の多くが対応しているのは P4-14
Portable Switch Architecture (PSA) • https://p4.org/p4-spec/docs/PSA-v1.0.0.html • P4における標準ライブラリの仕様。 ◦ C言語に例えるとlibcに相当するもの。
• リファレンス実装まで提供されているわけではない模様。 • 各ベンダーが? PSAのpackageを提供すると、開発が楽になる。 • P4-16用。 • 2018年3月に仕様が1.0になったばかりなので今すぐには使えない。
P4も万能ではない? • QoSはデバイスにより機能やパラメータが様々で、P4で標準化されていない ◦ meterとしてcolorをつけることまではできる。 • パケットのfragmentationやreassembleはできず、パケット生成機能はない • fast path,
slow pathといった帯域の割り当てはできない • テーブルサイズ(最大エントリ数)の指定はターゲット依存パラメータ • タイマーは用意されていない ベンダーによって違うが、独自パッケージとして提供していて(あるいは他の言語を使ってユーザが開発可能)、そのパッ ケージをP4を介して呼び出せるようにすることで解決できることがある。 • 例1 Netronome: C/C++で作成した機能とP4をSmartNIC内で接続できる • 例2 Mellanox: L2/L3機能は従来のASICのロジックが提供され利用可能
まとめ • P4を使うとベンダ非依存のデータプレーンのプログラミングができる • P4Runtimeが使えるようになると、設定なども標準化できる • PSAが普及すると開発がよりいっそう楽になる • 現在普及しているのはP4-14 •
P4-16への対応が今後の普及の鍵 • bmv2(ソフトウェア実装)を使えば、手元で試せる 誰もがカスタムデータプレーンを作れる時代がやってくる! (かもしれない)
参考資料 • プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック • P4のはなし • Announcing P4Runtime •
P4-based Dataplane with DPDK • P4/CによるSmartNICファームウェア開発の取組み