発表者紹介 名前 谷所基行 ( たにしょもとゆき ) 自画像 画数 8[ 画 ] 描画時間 5[s] 仕事 スイッチ装置アーキテクチャ検討 ASSP ドライバー開発 NPU マイクロコード開発 測定器ファームウェア開発 (SDT) その他 ときどき ハッカソンに参加 1

富士通アドバンストテクノロジ株式会社

システム技術統括部

谷所 基行

[email protected]

P4/Cを用いた

SmartNICファームウェア開発の

取り組み

発表者紹介

名前

 谷所 基行（たにしょ もとゆき）

仕事

 スイッチ装置アーキテクチャ検討

 ASSPドライバー開発

 NPUマイクロコード開発

 測定器ファームウェア開発（SDT）

その他

 ときどき、ハッカソンに参加

自画像

画数

8[画]

描画時間

5[s]

アジェンダ



取組み背景



P4の紹介



SmartNICによるPoC検証

スイッチデバイスの位置づけ

CPU

ASSP

性能

汎用性

プログラマブル

スイッチデバイス

(NPU, FPGA)

NIC

→ SmartNIC

デバイス変更

→ プログラム変更

CPU処理の

アクセラレーション

新しいプロト

プロトコルの

即時対応

例）VxLAN, INT, PTP

ASSP ... Application Specific Standard Product

NPU ... Network Processing Unit

スイッチ装置

概念図

装置構成と機能分担

プログラマブル

スイッチデバイス

(NPU, FPGA)

CPU

(x86, ARM,

PowerPC,

Z80, ...)

PCIe

Packet

In

Packet Out

コントロールプレーン

• Table Management

• OAM Processing

• ...

Lookup

Packet

Buffering

Counter,

Meter, etc

.

SRAM

DRAM

TCAM

データプレーン

• L2/L3 Switching, Routing, ...

• ACL

• Traffic Management

• ...

どうやって作る?

従来の開発手法



低水準言語による開発

1. スイッチデバイスのほぼ全般の知識が必要 → 熟練度に依存する

2. 設計資産が他のスイッチデバイスへ流用できない

RTL

FPGA

NPU

マイクロコード

C/C++

CPU

ソフトウェア

ネットリスト

独自アセンブラ/C

ハードウェアに近い

コーディング

ファームウェア

専用コンパイラ

合成

配置配線

GCC/LLVM

各々のアーキテクチャの理解

各々の言語知識

各々の開発環境の知識

パケット処理の仕様書

HW記述言語

あるべき開発手法

中間層 (デバイスに対し抽象化)

Compile(Front-end)

高位言語

1. 必要なスキルセットが少なく済む → 熟練度に依存しない

2. 設計資産が他のスイッチデバイスへ流用できる

Compile(Back-end)

各々のアーキテクチャの理解

各々の言語知識

各々の開発環境の知識

高位言語の知識

（仕様書にしても良い）

RTL

FPGA

NPU

マイクロコード

C/C++

CPU

ソフトウェア

ファームウェア

ネットリスト

専用コンパイラ

合成

配置配線

GCC/LLVM

不要

P4の特徴



標準化団体：P4.org（

https://p4.org/

）50社以上



デバイスベンダーや装置ベンダー、DC事業者など



ドメイン特化型高位言語：データプレーンを記述



プロトコル非依存、デバイス非依存



P4

₁₄

→ P4

₁₆

（

より柔軟なフォワーディングモデルに仕様変更）



Workshop：開催頻度年1,2回

（

https://p4.org/p4-workshop-2017/

）



P4をハードウェアに実装できる事例が増えてきている

•

Netronome, Barefoot, Netcope, ...



コミュニティ：Open-NFP

（

https://open-nfp.org/

）



データプレーン開発のためのコミュニティ（P4やeBPF、OvSなど）

データプレーン

P4のデータプレーンモデル

Parser

Extern

1. Parser (ヘッダー解析)

識別したいプロトコルを事前に定義（独自プロトコルも可）

2. Match (テーブル参照)

・Ingress Port, DA/SA, DIP/SIP, ...

・exact/ternary/lpm/...

3. Action (参照結果に従い、処理を実行)

・宛先（Port/Queue）決定

・パケット編集（フィールド書換え、ヘッダー追加/削除）

・廃棄

・カウンター など

プロトコル処理以外は外部オブジェクト

（例）チェックサム、Metering

Match

Action

Control

（記述1）Header definition

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;

}

}

header.p4

識別したいヘッダーを定義

※独自ヘッダー定義もOK

dst

dst

src

src

e_type

0

15

31

sip

ver

ihl

tos

len

id

flags

offset

ttl

protocol

checksum

dip

（記述2）Parser

#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.p4

parser

start

eth_hdr(14B)

extract

(eth);

eth_hdr

select

(eth.etype)

0x800

extract

(ipv4);

eth_hdr

ipv4(20B)

return

ingress;

（記述3）Control（Match Action）

#include

“parser.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;

}

control ingress

{

apply

(routing);

}

control.p4

eth(14B)

ipv4(20B)

reads

ipv4.dip :

lpm

;

DIP

control ingress

miss

/

hit

action

ip_drop();

do_drop();

action

route_ipv4();

（設定）Table configuration

table

Match

(ipv4.dip)

Action

action

src

port

routing

_10.1.2.3

_{route_ipv4}

_{00:11:aa:00:00:01}

₀

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はスイッチベンダーが提供

SmartNICによるPoC検証



性能検証



従来の開発手法との違い



コード量



工数

SmartNICによるアクセラレーション



サーバー負荷要因をオフロード

CPU

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

パケット処理

CPU

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

NIC

SmartNIC

プログラマブルではない

（機能追加できない）

OVS

_Balance

Load

IPsec

SDT

_...

アプリケーション

アプリケーション

パケット処理

性能検証（1）

SmartNIC

CPU



ホストに全部転送



パケット処理をすべてCPUにやってもらうことを想定



どれだけホストに転送できるかチェック

性能検証（2）



レイヤー4まで識別



オリジナルのテストヘッダーを定義

•

UDP Port = 55555なら、テストプロトコル

•

フィールドがMatchすれば、ホスト転送



自分宛のパケットでなければ、折り返す



SmartNICに高負荷をかけたいため

header_type

test_t {

fields

{

test_0 : 16;

test_1 : 16;

test_2 : 16;

test_3 : 16;

}

}

Eth

TEST

MAC

IPv4

UDP

SmartNIC

CPU

性能検証結果（1）

Case

Input rate

Output rate

ホスト転送

29,762[Kpps]

(20Gbps@64byte)

-[Kpps]

-P4

Firmware

20GE

SDT

Firmware

[DUT]

• Netronome Agilio-CX 1x40GE

[SDT]

性能検証結果（2）

Case

Input rate

Output rate

ホスト転送

29,762[Kpps]

(20Gbps@64byte)

-[Kpps]

ワイヤー転送

-[Kpps]

[DUT]

• Netronome Agilio-CX 1x40GE

[SDT]

• Netronome Agilio-CX 2x10GE

P4

Firmware

20GE

SDT

Firmware

コード量と工数比率

P4

（PoC実績）

マイクロコード

（過去の実績）

効果

開発コード量[step]

*

250

1,000

1/4

開発工数比率

**

0.3

1.0

1/3

* ファームウェアのみ（制御プログラム含まず）

** 全作業のうち、P4関連工数を算出. マイクロコードは

過去の開発実績からPoC相当の検討分を抽出

マイクロコード

P4

装置仕様検討、基本設計

装置仕様検討、基本設計

詳細設計、コーディング

単体試験

結合試験

結合試験

1. 最適化ほぼ不要

2. テーブル設定API作成不要

（制御プログラム作成工数削減）

3. 自動テーブルアサイン

（メモリ割当て検討不要）

PoC検証でわかったこと



P4でできること



データプレーンのプロトコル処理



コントロールプレーン用API（策定中）



マルチキャスト、ブロードキャスト

•

実際は外部オブジェクトによって実行される



P4でできないこと



QoS関連

•

スイッチデバイスによって機能的な違いが多い



パケット分割・結合処理



バックグラウンド用パイプライン



パケット生成機能



テーブル割り当て最適化



P4 ：プロトコル処理



C

：P4未対応機能

P4/Cを用いたSmartNICファームウェア開発

https://www.netronome.com/media/documents/WP_NFP_Programming_Model.pdf

C

P4

P4

Netronomeの開発環境であれば、C-Sandboxとして未対応機能が実現可能

まとめ



P4/Cを使った開発手法

P4の柔軟性を最大限活用し、

新たな市場ニーズに対応

いくつか制約はあるが、

データプレーンの開発効率は

高いと言える