P4/Cを用いた SmartNICファームウェア開発の取り組み 富士通アドバンストテクノロジ株式会社システム技術統括部谷所基行 fatec-ood-2017@dl.jp.fujitsu.com 0
発表者紹介 名前 谷所基行 ( たにしょもとゆき ) 自画像 画数 8[ 画 ] 描画時間 5[s] 仕事 スイッチ装置アーキテクチャ検討 ASSP ドライバー開発 NPU マイクロコード開発 測定器ファームウェア開発 (SDT) その他 ときどき ハッカソンに参加 1
アジェンダ 取組み背景 P4の紹介 SmartNICによるPoC 検証 まとめ 2
スイッチデバイスの位置づけ 性能 ASSP ASSP... Application Specific Standard Product NPU... Network Processing Unit FPGA... Field-Programmable Gate Array デバイス変更 プログラム変更 プログラマブルスイッチデバイス (NPU, FPGA) プロトコルの新しいプロト即時対応例 )VxLAN, INT, PTP CPU 処理のアクセラレーション NIC SmartNIC CPU 3 汎用性
装置構成と機能分担 スイッチ装置概念図 CPU (x86, ARM, PowerPC, Z80,...) コントロールプレーン Table Management OAM Processing... Packet Buffering Lookup Counter, Meter, etc. DRAM TCAM SRAM PCIe プログラマブルスイッチデバイス (NPU, FPGA) データプレーン L2/L3 Switching, Routing,... ACL Traffic Management... Packet In Packet Out どうやって作る? 4
従来の開発手法 低水準言語による開発 パケット処理の仕様書 ハードウェアに近いコーディング 独自アセンブラ /C HW 記述言語 C/C++ マイクロコード RTL 各々の言語知識 ソフトウェア GCC/LLVM ファームウェア 専用コンパイラ ネットリスト 合成配置配線 各々の開発環境の知識 CPU NPU FPGA 各々のアーキテクチャの理解 1. スイッチデバイスのほぼ全般の知識が必要 熟練度に依存する 2. 設計資産が他のスイッチデバイスへ流用できない 5
あるべき開発手法 高位言語 Compile(Front-end) 高位言語の知識 ( 仕様書にしても良い ) 中間層 ( デバイスに対し抽象化 ) Compile(Back-end) C/C++ マイクロコード RTL 各々の言語知識 ソフトウェア GCC/LLVM ファームウェア 専用コンパイラ ネットリスト 合成配置配線 不要 各々の開発環境の知識 CPU NPU FPGA 各々のアーキテクチャの理解 1. 必要なスキルセットが少なく済む 熟練度に依存しない 2. 設計資産が他のスイッチデバイスへ流用できる 6
P4 の特徴 標準化団体 :P4.org(https://p4.org/)50 社以上 デバイスベンダーや装置ベンダー DC 事業者など ドメイン特化型高位言語 : データプレーンを記述 プロトコル非依存 デバイス非依存 P4 14 P4 16 ( より柔軟なフォワーディングモデルに仕様変更 ) Workshop: 開催頻度年 1,2 回 (https://p4.org/p4-workshop-2017/) P4 をハードウェアに実装できる事例が増えてきている Netronome, Barefoot, Netcope,... コミュニティ :Open-NFP (https://open-nfp.org/) データプレーン開発のためのコミュニティ (P4 や ebpf OvS など ) プロジェクト数 :50 超 (Firewall, INT, DDoS Detection など ) 7
P4 のデータプレーンモデル 1. Parser ( ヘッダー解析 ) 識別したいプロトコルを事前に定義 ( 独自プロトコルも可 ) 2. Match ( テーブル参照 ) Ingress Port, DA/SA, DIP/SIP,... exact/ternary/lpm/... 3. Action ( 参照結果に従い 処理を実行 ) 宛先 (Port/Queue) 決定 パケット編集 ( フィールド書換え ヘッダー追加 / 削除 ) 廃棄 カウンターなど Control データプレーン Parser Match Action Extern プロトコル処理以外は外部オブジェクト ( 例 ) チェックサム Metering 8
( 記述 1)Header definition header.p4 header_type eth_hdr { fields { dst : 48; src : 48; e_type : 16; header_type ipv4_hdr { fields { version : 4; ihl : 4; diffserv : 8; len : 16; id : 16; flags : 3; offset : 13; ttl : 8; protocol : 8; checksum : 16; sip : 32; dip : 32; 識別したいヘッダーを定義 独自ヘッダー定義も OK 0 15 31 dst e_type dst src sip src 0 15 31 ver ihl tos len id flags offset ttl protocol checksum dip 9
( 記述 2)Parser parser.p4 #include header.p4 header eth_hdr eth; header ip4_hdr ipv4; parser start { return parse_eth; parser parse_eth { extract(eth); return select(eth.etype) { 0x800: parse_ipv4; default: ingress; parser parse_ipv4 { extract(ipv4); return ingress; parser start extract(eth); eth_hdr(14b) select(eth.etype) eth_hdr 0x800 extract(ipv4); eth_hdr return ingress; ipv4(20b) 10
( 記述 3)Control(Match Action) #include parser.p4 control.p4 action do_drop() { ip_drop(); drop(); action route_ipv4(src, port) { modify_field(eth.src, src); modify_field(standard_metadata.egress_port, port); table routing { reads { ipv4.dip : lpm; actions { do_drop; route_ipv4; size : 1024; eth(14b) control ingress reads ipv4.dip : lpm; ipv4(20b) action ip_drop(); do_drop(); DIP miss / hit action route_ipv4(); control ingress { apply(routing); 11
( 設定 )Table configuration table Match (ipv4.dip) Action action src port routing 10.1.2.3 route_ipv4 00:11:aa:00:00:01 0 10.0.1.2 route_ipv4 00:22:bb:00:00:02 1 10.0.1.3 route_ipv4 00:33:cc:00:00:03 2... *.*.*.* do_drop (default) - - P4 として明確なフォーマットは規定されていない テーブル設定 API はスイッチベンダーが提供 12
SmartNIC による PoC 検証 性能検証 従来の開発手法との違い コード量 工数 13
SmartNIC によるアクセラレーション サーバー負荷要因をオフロード CPU CPU アプリケーション アプリケーション パケット処理 NIC SmartNIC パケット処理 プログラマブルではない ( 機能追加できない ) プログラマブル オフロード可能 OVS Load Balance SDT IPsec... 14
性能検証 (1) ホストに全部転送 パケット処理をすべてCPUにやってもらうことを想定 どれだけホストに転送できるかチェック CPU SmartNIC 15
性能検証 (2) レイヤー 4 まで識別 オリジナルのテストヘッダーを定義 UDP Port = 55555 なら テストプロトコル フィールドが Match すれば ホスト転送 自分宛のパケットでなければ 折り返す SmartNIC に高負荷をかけたいため MAC Eth IPv4 UDP TEST header_type test_t { fields { test_0 : 16; test_1 : 16; test_2 : 16; test_3 : 16; CPU SmartNIC 16
性能検証結果 (1) SDT Firmware 20GE P4 Firmware [SDT] Netronome Agilio-CX 2x10GE [DUT] Netronome Agilio-CX 1x40GE Case Input rate Output rate ホスト転送 29,762[Kpps] (20Gbps@64byte) -[Kpps] - 17
性能検証結果 (2) SDT Firmware 20GE P4 Firmware [SDT] Netronome Agilio-CX 2x10GE [DUT] Netronome Agilio-CX 1x40GE Case Input rate Output rate ホスト転送 ワイヤー転送 29,762[Kpps] (20Gbps@64byte) -[Kpps] -[Kpps] 18
コード量と工数比率 P4 (PoC 実績 ) マイクロコード ( 過去の実績 ) 効果 開発コード量 [step] * 250 1,000 1/4 開発工数比率 ** マイクロコード 装置仕様検討 基本設計 0.3 1.0 1/3 * ファームウェアのみ ( 制御プログラム含まず ) ** 全作業のうち P4 関連工数を算出. マイクロコードは過去の開発実績から PoC 相当の検討分を抽出 詳細設計 コーディング単体試験結合試験 P4 装置仕様検討 基本設計 結合試験 1. 最適化ほぼ不要 2. テーブル設定 API 作成不要 ( 制御プログラム作成工数削減 ) 3. 自動テーブルアサイン ( メモリ割当て検討不要 ) 19
PoC 検証でわかったこと P4 でできること データプレーンのプロトコル処理 コントロールプレーン用 API( 策定中 ) マルチキャスト ブロードキャスト 実際は外部オブジェクトによって実行される P4 でできないこと QoS 関連 スイッチデバイスによって機能的な違いが多い パケット分割 結合処理 バックグラウンド用パイプライン パケット生成機能 テーブル割り当て最適化 20
P4/C を用いた SmartNIC ファームウェア開発 P4 C : プロトコル処理 :P4 未対応機能 P4 C P4 Netronome の開発環境であれば C-Sandbox として未対応機能が実現可能 https://www.netronome.com/media/documents/wp_nfp_programming_model.pdf 21
まとめ P4/C を使った開発手法 いくつか制約はあるが データプレーンの開発効率は 高いと言える P4 の柔軟性を最大限活用し 新たな市場ニーズに対応 22