High PerformanceNetworking 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 ほんとはここまでやりたかった。。 (だれかお金)
NICsNIC
0 Rx
CPU socket0
NIC1
Rx
Core0
NIC0 Tx
NIC1 Tx
Core1
Core2
Core3
Core4
Core5
Core6
Core7
Software
DPDKと知恵
PCIeNICs
NIC2
Rx
CPU socket1
NIC3
Rx
Core0
NIC2 Tx
NIC3 Tx
Core1
Core2
Core3
Core4
Core5
Core6
Core7
NUMA
RAM1
RAM0
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→0Port0の受信を監視するスレッドPort0の送信を監視するスレッドPort1の受信を監視するスレッドPort1の送信を監視するスレッド
NIC0 Rx
NIC1 Rx
Rx0Thrd
NIC1 Tx
NIC0 Tx
Rx1Thrd
Tx1 Thrd
Tx0 ThrdFlow 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 TxFlow 1→0 Thrd
Flow 0 →1 Thrd
NIC0 Rx
NIC1 Rx
Rx0Thrd
NIC1 Tx
NIC0 Tx
Rx1Thrd
Tx1 Thrd
Tx0 ThrdFlow 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 TxFlow 1→0 Thrd
Flow 0 →1 Thrd
NIC0 Rx
NIC1 Rx
Rx0Thrd
NIC1 Tx
NIC0 Tx
Rx1Thrd
Tx1 Thrd
Tx0 ThrdFlow 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 TxFlow 1→0 Thrd
Flow 0 →1 Thrd
NIC0 Rx
NIC1 Rx
Rx0Thrd
NIC1 Tx
NIC0 Tx
Rx1Thrd
Tx1 Thrd
Tx0 ThrdFlow 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 TxFlow 1→0 Thrd
Flow 0 →1 Thrd
NIC0 Rx
NIC1 Rx
Rx0Thrd
NIC1 Tx
NIC0 Tx
Rx1Thrd
Tx1 Thrd
Tx0 ThrdFlow 1→0 Thrd
Flow 0→1 ThrdRxの処理がボトルネックっぽい
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!
Top Related