- 日時: 2015-04-09 17:30〜19:00
- 会場: IIJ飯田橋 13F Opera2会議室
- 告知: http://www.iij-ii.co.jp/lab/seminars/index.html
- まとめ: http://togetter.com/li/806328
ネクタイしている人がいないようなので,いきなり技術的な話でokらしい。
[2015-04-09 17:31]
Networking Operating System from Scratch towards High-Performance COTS Network Facilities
浅井大史 Hirochika Asai (東京大学)
- BSDとかのネットワークスタックには贅肉がたくさんあってボトルネックがわかりにくいのでスクラッチで書くことにした。
- OSは趣味→ドクターのときに仕事化
- クラウドでコモディティ化→ネットワークがソフトウェア化している
- forwardingはハードで、routingはソフトで。
- NFV:仮想マシンをつかうのはオーバヘッドがあってチャレンジングだけど。
- OSとは?
- リソースマネージメント
- ネットワークは周辺機器から中心になってきた
- スクラッチのイイコト
- ブラックボックスがない(ハードウェアの限界がわかる)
- アルゴリズムやアーキテクチャの追求
- 汎用のCPUをつかう
- まずはフルルートをあつかえるルーターをつくってみよう
- VFSR: very fast software router
- fast packet forwarding (専用チップをつかわずに)
- fast ip routing table lookup (TCAMをつかわずに)
- Ethernetでの速いとはどのくらい?
- 10GbE: 64B 14.88Mpps = 67.2ns/packet
- 100GbEだとこれの1/10になる。つらい。
- 40GbEくらはみえてきた。
- おそいのはなぜ?
- CPU slow? mem copy? intr overhead?
- CPUは0.3ns/cpu-cycle (3.3GHz)
- memcpyは DDR3-1866 ならスループットはたりてる
- 割り込み処理自体は重くない
- PCIeのNICはmemory mapped IO (MMIO)でレジスタアクセスする。
- RAIDカードでは250ns/accessくらいかかると論文に書いてあった。
- NICで測ってみたらread 392.1ns、write 72.47nsくらいかかった。
- PMCで測った。100万回くりかえし。
- RAIDでの値はreadとwriteの平均っぽい。
- Generic NIC arch
- ring buffer→Descriptor→Buffer
- ringバッファの大きさは2の羃とはかぎらないが、divは18cycleくらい。ちょっと最適化の余地。
- 8個くらいまとめて書くと性能が出る
- readが遅いので read_txq_head() をなくした by Intel (XL710) write-backをつかうようになった。
- check_wb_statuss()をつかうように
- でも性能が出ない。。
- ring bufferは複数ある。RSS
- 40G line rateが出ないのはしかたがない(XL710) by Intelさん
- ポーリングはレイテンシが伸びるといわれているが全力でやれば10us以下になる。(大型のルータよりは速いくらい)(小型のには負ける)
- テスターで送信してソフトルータでおりかえしてテスターにもどってくる。
- 全力ポーリングなので電気を喰うけど。
- CPUのレジスタが増えた(15個)ので割り込みで退避のコストがふえた。push/popはスループット1→30 CPU cycle.
- レジスタはmust preserveかfreeのどちらかしかない。ABIを変えるしかない。。
- コアをふやすといけるのは割り込みハンドラのコストがならされるからか?
- PCIのMMIOが遅い→バルク処理しよう。
- 割り込みハンドラの処理が無視できない→ポーリング
- ルーティング: longest prefix match
- binary radix treeで実現すると深くなったときに遅い+ポインタたどるのおそい
- 深さを減らすのにmulti arrayのtriにした。メモリへらした。
- 800k lookupできるようなった。
- socket APIをなんとかしようということもやっている。
- 低レイヤーのプログラミングをしなくてもsocketでルータをつくれるように。
- SOCK_DGRAM + IPPROTO_ETHERNETとか
[2015-04-09 18:16]
Q: OSのはなしはいつごろきける?
A: 半年後くらい?
Q: MACアドレスをバインドするのは?
A: 仮想NICを開くかんじ。2つひらくとルーターに。
Q: ハード割り込みを軽くするだけじゃなだめ?
A: 単純な処理しかしないのに、お決まりの処理が重い。
[2015-04-09 18:20]
[2015-04-09 18:20]
Seastar: 高スループットなサーバアプリケーションの為の新しいフレームワーク
浅田拓也 (Cloudius Systems)
- シースター
- Cloudius: OSvをつくっているベンチャー企業
- Avi Kivity: CTO, KVMをつくったひと.
- seastar: NoSQL, memcachedなどサーバアプリを速くしたい。
- OSvの経験からAPIを変えずに高速化するのは困難。
- OSvでも動くが、メインターゲットはlinux.
- コアがたくさんある、コアの性能は上がらない、NIC/SSDはどんどん速くなっている。
- 既存のネットワークスタックの問題
- 共有データがあるので操作コストが大きい。NUMAの場合はCPUからmemが遠いとさらに遅くなる。
- socket APIの構造的な問題。
- Seaster
- shared nothingプログラミングモデルに。
- CPU間はメッセージパッシング
- DPDKでカーネルをバイパス
- no thread(1thread/core), no context sw, no locking.
- カーネルバイパスの必要性
- socket APIだとzerocopyがやりにくい(もしくは困難)
- プロセス処理とアプリが同じコアで実行できずキャッシュコヒーレンシで遅くなったり
- プロトコル処理のところのロック競合したり
- ユーザランドとカーネルのきりかえオーバヘッド
- DPDK
- intelが中心になって、フレームワーク
- スレッドはpinされる
- メモリアロケートも独自。かつhugetlbfsで2MB単位でページをとる。
- NICはパススルーデバイス経由で直接mmapしてたたく。
- ポーリング。(最近は割り込みもつかえるようになったらしい)
- ネットワークスタックは持たない(DPDKの上でやること)
- アプリにはmbufがとどいたようにみえる。
- seastarはDPDKの上のネットワークスタック
- ネットワークIOでシステムコールをつかう必要なし。
- socket API非互換
- 対応プロトコル: TCPv4, UDPv4, IPv4,ARP,DHCP
- packet forwarding用途は考えてない。。。
- C++14, Future/Promise/Continuationモデルによる非同期API
- これらをつかってスケジューラを実装。
- std::のfutureとは別物で独自実装。(汎用じゃなくてよいので: ロックしない、メモリアロケートしない、continuationサポート)
- C++のlambda式をはじめて見た人は? → 会場の3分の1くらい?
- Future/Continuation: lambda式で完了時のcallbackを指定する感じ?
- zero copy RX
- ドライバからのページが直接みえてるが、scatter-gatherは自動でおこなわれる。
- zero copy TX
- TCP windowが開くのを待つfutureとバッファが空くのを待つfutureの2つをつかう。
- class distributed
をつかって複数CPUで実行できる。(threadはpinされる) - app.startではcpu0で実行れている。
- CPU間通信
- smp::submit_to(neighbor, [key]{return xxx[key]} でneighbor上でreturn xxx[key]が実行される。
- ポインタはスマートポインタも含めて使わない。std::move()をつかえ。
- seastartのスケジューラ
- future/promiseがキューに積まれて、条件が成立したらlambdaが呼ばれる。
- CPU間でキューが融通されることはない。
- userland threadとの違いはコンテキスト切り替えがないこと。
- RSSが使えない環境では1CPUでハッシュ値を計算して分散させるのにも対応。
- malloc/free/realloc/memalign/new/deleteはフックして独自実装。
- TCPのコネクションの状態はどう管理する?
- 同一コネクションのパケットは同一CPUに来るようにしているのでTCP stateを共有する必要はない。
- ハッシュ値計算はNICがやってくれる。
- 知らないパケットが届いたらRST。
- memcachedのaddの実装例
- addとgetが別CPUになると困る→addのときにsubmit_toで他のCPUに複製しちゃう戦略で解決。(NCPU重複だが共有するよりはまし?)
- seaster API
- future/promise/continuation
- network IO
- file IO
- timer
- HTTP(for server only?)
- JSON(swagger)
- RPC (よくわかんね)
- POSIX API wrapper
- collectd client (logging daemon)
- ネットワークバックエントでつかえるもの: DPDK,vhostnet,Xen(OSv),socket
- DPDK on OSvを実装中 (SR-IOVが対応してるので)
- OSvがベアメタル上で動くようになるかも?
- memcachedベンチマーク
- seastar: リニアに性能が出ている(20コア)
- stock: マルチスレッド版はスケールしてない。(マルチプロセスの方がまし)
- 他のDPDK向けのネットワークスタック
- apiは従来どおりで、ほぼsocket apiとおもわれる。
- 既存アプリとの互換性は高いとおもわれる。
- 多言語対応
- スクリプト言語に対応しても意味なさげ
- 議論はしているが作業はしてない。募集中。golang?
[2015-04-09 19:26]
Q: SMPのキャッシュコヒーレンシはどうしてる?
A: あとで調べてみる
Q: RSSでフラグメントしてたら?
A: NICのoffloadにたよればたぶんok。
Q: 保護違反したときの対応はどう?
A: 実運用では切り離しするなど対応が必要だろう。
Q: div0したら
A: プロセスが死ぬだけ
[2015-04-09 19:33]
久し振りに首藤さんに会った。懇親会に行くかラーメン食って帰るか悩んでた。