KEMBAR78
High Performance Networking with DPDK & Multi/Many Core | PDF
High Performance
Networking with
DPDK & Multi/Many Core
Hiroki Shirokura (@slankdev)
自己紹介
▣ 城倉 弘樹 (Hiroki Shirokura)
□ Twitter: @slankdev
□ Github: slankdev
▣ 法政大学 理工学部 B3
ネットワークセキュリティ専攻
▣ 昨年
□ Cybozu labs Youth 5,6th
□ IPA Security Camp 2015, 2016 tutor
▣ NW, NW, NW, NW, NW, Vim, Vim, Vim, HW入門
Cybozu Labs Youth
自分で発案したソフトウェア研究開発を
サイボウズラボが技術/金銭面で支援するプロジェクト
権利などもすべて本人に帰属。超すごい人が指導してくれる
STCP: high performance network stack on DPDK
高性能TCP/IPネットワークスタック
Linux, DPDK, C++11
https://github.com/slankdev/stcp
研究開発テーマ (メンター: 光成滋生氏)
- 高性能ネットワークスタック
- 拡張可能なパケット解析フレームワーク
先日: Xeon Phiで高性能ネットワーキング実験した
Xeon Phi + X540-T2 x2
だたつかうだけでは
良い性能は出なかったよ!
1つのコアはしょぼい
(Atomベース)
Cat 5/6のケーブルも結構すごい
10GBase-Tのリンクできる
速度もでる
そもそも規格はケーブル長100mでの
性能を保証するもの
←彼はザコケーブルが奮闘したのに
 腹を立ててケーブルをいじめ始めた
 皮膜をはがして磁石や蛍光灯に...
ってことで
マルチコア/メニーコアで高性能ネットワーキングするために
調べたら知見がいくつかあったので報告します。
‘’
Agenda
1. DPDKとは何かを理解する
2. マルチコア, メニーコア時代の
NW処理の入り口に立つ
3. 高性能なpacket forwarderの
設計パターンをすこし
What is DPDK …?
Hardware
User Land
Kernel Land
APP
低
速
Hardware
User Land
Kernel Land
APP
DPDK
超
高
速
DPDKを使用 Linuxを使用カーネル経由で遅い
(Intel) DataPlane Developing Kit
▣ SWによる高速NW処理を実現するライブラリ
▣ ユーザランドからカーネルをバイパスして高速に動作
▣ Openflowスイッチとかソフトルータとか
What is DPDK …?
- CPU100%のbusy-loopでポートを監視して
低遅延にパケットIOを行う
- ユーザランドからデバイスを直接制御
- 詳しくはdpdk.orgを見ましょう
Benefit to use DPDK
- Kernelの多大なContextを回避
- ただ使うだけでパケットIOが早くなります
- でももっとすごくできます
- CPUに直接処理を割り当てる
- NICのPort (Queueレベル)をpolling
- timewaitなしのbusy-wait
Approach
- Port管理、スレッド操作
- どのように複数コアを使おう....
DPDK Trends
- Kamuee0 (NTT Com)
- Lagopus (NTT R&D)
- Seaster (Cloudius Systems)
- FD.io (Cisco, Ericsson, Intel, etc)
- 自作OS ...?
- FPGA NIC
- ASIC (NPU, etc)
SWでできれば低価格、高拡張性!
SW最適化
DPDKが多い
プロは自作OS ?
HW最適化
本日考えること
Basic Packet Forwarding (2 ports) with DPDK
とっても簡単
DUT
(Device
Under Test)
ReceiverTransmitter
ここを
低遅延,
高スループット
に実装する
DPDK Usecase [ex]: Lagopus (Openflow Switch)
引
用:http://www.slideshare.net/jstleger/dpdk-summit-08-sept-
2014-ntt-high-performance-vswitch
では
NW機器の実装する
- それぞれのコアを
どのような用途で使うか
- それぞれのNICをどのように操作するか
パケット処理の規模によっても最適なパターンがありそう
10GNIC買って, なるべくコアの多いマシン用意して, DPDKをうまく操作して
いろんなパターンでできるだけ試して調べてみよう!!!
用意するThreadは以下の三つの組み合わせ
- Tx: Transmission
- Rx: Receive
- Wk: Worker (Flowing, Routing, etc..)
これらを組み合わせる
Test Environment
- NICは店頭購入だと7万くらい, Amazonだと2.5万くらいです
- NIC以外は借り物
VIM01 (DUT) VIM02 (Tester)
CPU Intel Core i7 3770 @3.9GHz (8 core) Intel Core i7 2700K @3.5GHz (8 core)
RAM 16GB 8GB
NIC Intel X540 T2 (10GbE x2) Intel X540 T2 (10GbE x2)
OS Ubuntu 16.04 LTS Xenial Ubuntu 16.04 LTS Xenial
Kernel 4.4.0-57-generic 4.4.0-31-generic
DPDK ver 16.07 ver 16.07
Test Network
10GbE
Network
Control Network DUT
Tester
PCIe
Test Ptterns 題目: 8Core CPU, 10GNIC x2で何かする
NICs
NIC0
Rx
CPU
NIC1
Rx
Core0
NIC0
Tx
NIC1
Tx
Core1 Core2 Core3
Core4
- 必要な機能
- パケット受信
- パケット送信
- 送信先決定 (今回は空の関数)
- どこにそれぞれ何コア
割り当てるか
- 評価項目はスループット
Core5 Core6 Core7
Software
DPDKと知恵
PCIe
Test Ptterns ほんとはここまでやりたかった。。 (だれかお金)
NICs
NIC
0
Rx
CPU socket0
NIC
1
Rx
Core
0
NIC
0 Tx
NIC
1 Tx
Core
1
Core
2
Core
3
Core
4
Core
5
Core
6
Core
7
Software
DPDKと知恵
PCIe
NICs
NIC
2
Rx
CPU socket1
NIC
3
Rx
Core
0
NIC
2 Tx
NIC
3 Tx
Core
1
Core
2
Core
3
Core
4
Core
5
Core
6
Core
7
N
U
M
A
RAM
1
RAM
0
Money Money Money Money Money Money Money Money Money Money Money Money
Test Pattern
今回はこれから紹介する5種類のマルチスレッドパターンで
実験をします。
- 一般的スレッドパターン
- TxRx独立パターン
- ポート独立パターン
- ポートTxRx独立パターン
- 固有フロースレッドパターン
- フロー独立パターン
- フローTxRx独立パターン
処理の分割の粒度、分割条件などに対して後ほど考察するので
皆さんも考えてみましょう
Patterns: 一般的スレッドパターン シンプル
NIC0
Rx
NIC1
Rx
Rx
Thrd
NIC0
Tx
NIC1
Tx
Tx
Thrd
Wk
Thrd
NIC0
Rx
NIC0
Tx
Port0
Thrd
NIC1
Rx
NIC1
Tx
Port1
Thrd
Wk
Thrd
TxRx独立パターン
Port0,Port1の受信処理を監視するスレッド
Port0,Port1の送信処理を監視するスレッド
パケット処理を行うスレッド
ポート独立パターン
Port0の送受信を監視するスレッド
Port1の送受信を監視するスレッド
パケット処理を行うスレッド
ポートTxRx独立パターン
Port0の受信を監視するスレッド
Port0の送信を監視するスレッド
Port1の受信を監視するスレッド
Port1の送信を監視するスレッド
パケット処理を行うスレッド
NIC0
Rx
NIC1
Rx
Port0
Rx
Thrd
NIC0
Tx
NIC1
Tx
Wk
Thrd
Port1
Rx
Thrd
Port0
Tx
Thrd
Port1
Tx
Thrd
Patterns: 固有フロースレッドパターン
NIC0
Rx
NIC1
Rx
NIC1
Tx
NIC0
TxFlow 1→0 Thrd
Flow 0 →1 Thrd
フロー独立パターン
Port0→Port1のパケット転送スレッド
Port1→Port0のパケット転送スレッド
フローTxRx独立パターン
パケット転送スレッド 0→1
パケット転送スレッド 1→0
Port0の受信を監視するスレッド
Port0の送信を監視するスレッド
Port1の受信を監視するスレッド
Port1の送信を監視するスレッド
NIC0
Rx
NIC1
Rx
Rx0
Thrd
NIC1
Tx
NIC0
Tx
Rx1
Thrd
Tx1
Thrd
Tx0
Thrd
Flow 1→0 Thrd
Flow 0→1 Thrd
TxRx独立パターン
ポート独立パターン
ポートTxRx独立パターン
Result
Num Cores 4 5 6 7 8
Thoughput [bps] 8.4 8.4 8.4 8.4 8.4
Num Cores 4 5 6 7 8
Thoughput [bps] - - 8.4 8.4 8.4
Num Cores 4 5 6 7 8
Thoughput [bps] 8.4 8.4 8.4 8.4 8.4
フロー独立パターン
フローTxRx独立パターン
※ pkt size = 64byte
Wirerate ≒ 8.4Gbps
Num cores 3~
Thoughput [bps] 8.4
Num cores 7~
Thoughput [bps] 8.4
どのパターンでもwirerate
Note
Core i7 & x540 強すぎた。。
このままではまずいのでWorkerスレッドにdelayを入れて
実際のスイッチとかルータくらいの遅延(持て余さない程度)
を入れて再度実験
TxRx独立パターン
ポート独立パターン
ポートTxRx独立パターン
Result2 : wk-delay=15000clk
Num Cores 4 5 6 7 8
Thoughput [bps] 2.3 4.6 6.8 8 7
Num Cores 4 5 6 7 8
Thoughput [bps] - - 2.3 4.6 6.9
Num Cores 4 5 6 7 8
Thoughput [bps] 2.4 4.6 6.9 8.1 7
Result2 : wk-delay=15000clk
でもなんだかよくわからない
性能悪化がある
リニアにスケールする!!
Note
原因がわかならくていろいろ試したが原因不明
- 相性の悪いコアをつかってしまったか。。
- lcore7が壊れているのか。。。
別のコアを割り当てて確かめればよかった(今更)
Result3 : wk-delay=32000clk
一応別のdelay値(=32000clk)を入れて同様の試験を行った。
同じ
結果
つらい
気を取り直して
今回はWorkerスレッドの遅延を自分でコントロールしてしまった。
でも実際はそうはならない。
どうすればいいか
ホットスポットがある場合に考えられる犯人は
- Workerスレッド
- ポート監視スレッド
- データ共有など
もしボトルネック処理のコアが足りなくて、
それ以外で持て余してたらそれをわけてあげたら...
Discussion
分割の粒度
- 処理の規模が大きいほど
よい影響がありそう
- 規模が大きくないのを
無理に分割すると
オーバーヘッドになりそう
→ホットスポットの粒度を
 あげればなんか気持ちよく
 なれそう
処理の分割
- ポート分散→別ポートが安定
- 機能分散 →別の機能が安定
- Flow分散 →別Flowが安定
選択のポイント
- どれに負担がかかるのか
- どれを安定させたいのか
別NUMAノードで
malloc/freeすると遅いって噂
性能でないときの犯人探し
先ほどの各スレッドの遅延を地道に測った ↓こいつら
NIC0
Rx
NIC1
Rx
Rx
Thrd
NIC0
Tx
NIC1
Tx
Tx
Thrd
Wk
Thrd
NIC0
Rx
NIC0
Tx
Port0
Thrd
NIC1
Rx
NIC1
Tx
Port1
Thrd
Wk
Thrd
NIC0
Rx
NIC1
Rx
Port0
Rx
Thrd
NIC0
Tx
NIC1
Tx
Wk
Thrd
Port1
Rx
Thrd
Port0
Tx
Thrd
Port0
Tx
Thrd
NIC0
Rx
NIC1
Rx
NIC1
Tx
NIC0
Tx
Flow 1→0 Thrd
Flow 0 →1 Thrd
NIC0
Rx
NIC1
Rx
Rx0
Thrd
NIC1
Tx
NIC0
Tx
Rx1
Thrd
Tx1
Thrd
Tx0
Thrd
Flow 1→0 Thrd
Flow 0→1 Thrd
130-270 clk170-620 clk
130-190 clk 260-490 clk230-810 clk
性能でないときの犯人探し
先ほどの各スレッドの遅延を地道に測った ↓こいつら
NIC0
Rx
NIC1
Rx
Rx
Thrd
NIC0
Tx
NIC1
Tx
Tx
Thrd
Wk
Thrd
NIC0
Rx
NIC0
Tx
Port0
Thrd
NIC1
Rx
NIC1
Tx
Port1
Thrd
Wk
Thrd
255-950 clk
NIC0
Rx
NIC1
Rx
Port0
Rx
Thrd
NIC0
Tx
NIC1
Tx
Wk
Thrd
Port1
Rx
Thrd
Port0
Tx
Thrd
Port0
Tx
Thrd
NIC0
Rx
NIC1
Rx
NIC1
Tx
NIC0
Tx
Flow 1→0 Thrd
Flow 0 →1 Thrd
NIC0
Rx
NIC1
Rx
Rx0
Thrd
NIC1
Tx
NIC0
Tx
Rx1
Thrd
Tx1
Thrd
Tx0
Thrd
Flow 1→0 Thrd
Flow 0→1 Thrd
130-270 clk170-620 clk
130-190 clk 260-490 clk230-810 clk
性能でないときの犯人探し
先ほどの各スレッドの遅延を地道に測った ↓こいつら
NIC0
Rx
NIC1
Rx
Rx
Thrd
NIC0
Tx
NIC1
Tx
Tx
Thrd
Wk
Thrd
NIC0
Rx
NIC0
Tx
Port0
Thrd
NIC1
Rx
NIC1
Tx
Port1
Thrd
Wk
Thrd
255-950 clk
NIC0
Rx
NIC1
Rx
Port0
Rx
Thrd
NIC0
Tx
NIC1
Tx
Wk
Thrd
Port1
Rx
Thrd
Port0
Tx
Thrd
Port0
Tx
Thrd
NIC0
Rx
NIC1
Rx
NIC1
Tx
NIC0
Tx
Flow 1→0 Thrd
Flow 0 →1 Thrd
NIC0
Rx
NIC1
Rx
Rx0
Thrd
NIC1
Tx
NIC0
Tx
Rx1
Thrd
Tx1
Thrd
Tx0
Thrd
Flow 1→0 Thrd
Flow 0→1 Thrd
130-270 clk170-620 clk
130-190 clk 260-490 clk230-810 clk
性能でないときの犯人探し
先ほどの各スレッドの遅延を地道に測った ↓こいつら
NIC0
Rx
NIC1
Rx
Rx
Thrd
NIC0
Tx
NIC1
Tx
Tx
Thrd
Wk
Thrd
NIC0
Rx
NIC0
Tx
Port0
Thrd
NIC1
Rx
NIC1
Tx
Port1
Thrd
Wk
Thrd
255-950 clk
NIC0
Rx
NIC1
Rx
Port0
Rx
Thrd
NIC0
Tx
NIC1
Tx
Wk
Thrd
Port1
Rx
Thrd
Port0
Tx
Thrd
Port0
Tx
Thrd
NIC0
Rx
NIC1
Rx
NIC1
Tx
NIC0
Tx
Flow 1→0 Thrd
Flow 0 →1 Thrd
NIC0
Rx
NIC1
Rx
Rx0
Thrd
NIC1
Tx
NIC0
Tx
Rx1
Thrd
Tx1
Thrd
Tx0
Thrd
Flow 1→0 Thrd
Flow 0→1 Thrd
Rxの処理がボトルネックっぽい
Multi Queue NICを有効活用
すれば良さそう
(時間の関係により懇親会などで)
Next
- 試せていない項目
- Multi Queue/RSS/Flow Director
- NUMA
- Bonding
- Hardware Offloading Option
- 知り合いがXeon Phi KNLを持っているので、
256コアマシンで実験してきます。
- やり足りない項目
- Multi core操作 -> よりスマートにやりたい
- 実際にルータ程度のものを書くか...
- 今回の知見をネットワークスタックに移植する
- また違ったアプローチ
- 独自アーキテクチャ
- FPGAでのアクセレーション
Conclusion
だれよりも早いパケット処理したい! -> DPDKおすすめです
DPDKつかうのは結構簡単です。 -> サンプルうごかしてください
でもそれではぜんぜんまだまだです。
環境に最適に動かすこと考えましょう。
もっというとチューニングしないでも早く動いてほしい
要するに自分でためして知見を得る
みんなで協力することが重要だ
Special Thanks
- サイボウズ・ラボ株式会社 (Cybozu Labs Youth)
- 光成滋生氏 研究開発を指導
- 星野喬氏  マシンを借用
- 法政大学大学院理工学研究科
- 金井敦先生 マシンを借用
- Akira氏 (@akiranet2580) 実験の手伝い、目覚まし
- 東京大学情報理工学研究科 加藤真平研究室
- Xeon phiマシンを借用
Thanks!

High Performance Networking with DPDK & Multi/Many Core