IIJ Technical WEEK 2014 1日目 #iij_tw2014
- IIJ_doumae
- 4871
- 0
- 2
- 53
続き)カーネルメモリを共有する(Lagopusでは使われてないが、netmapなど)。カーネルを介さずに送受信処理をする。(DPDK)LagopusではDPDKを使っている。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:08:47コンテキストスイッチ対策。割り込みやプロセス切り替えで発生するのがコンテキストスイッチ。オーバーヘッドがあるのでこれを減らす工夫。割り込みを減らす(しない)、プロセス切り替えをしない。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:09:52パケットの流量を見て、パケットが沢山流れてきそうなときはポーリングすることで割り込みしない。(Linux NAPI)DPDKでは常にポーリングしている。これで割り込みの回数を極端に減らせる。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:10:55プロセス切り替えを減らす工夫。kernelのcore affinity指定でコアを占有する。(DPDK)プロセス切り替えせずに、特定のコアでプログラムが走り続けられるようにする。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:11:45ページフォルトとは。4KB/page単位でメモリ管理している。TLBで物理メモリ/論理メモリのマッピングを管理している。TLBで内場合は例外が発生してOSがハンドリングしてTLBの内容を入れ替える。これが普通。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:13:02ページフォルトを減らすために。hugepage(2MB/page,1GB/page)というやり方。プロセッサが提供しているがOSのサポートも必要。ファイルシステムfugetlbfs経由で使う。Lagopus #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:14:16バスをまたいだI/O・メモリアクセス。大規模システムだと、複数のCPUが搭載されていて、それぞれがバスを持っている。どちらのバスに搭載されたデバイスでも、どちらのCPUからアクセスできるが、(続く #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:15:27あるCPUから他方のCPUバスのメモリ・デバイスにアクセスすると当然遅い。速度低下を起こさないように、自分のバスにつながっているメモリ・デバイスを使うように仕向ける。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:16:09OpenFlowの性能を高める工夫。幾つかある。最初はフロー探索アルゴリズム。10万フローエントリを頭からスキャン→遅すぎる。Xeon 2.2GHzで20Kbpsしか出ない。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:17:07OpenFlowの仕様による制約。マッチ対象のフィールドは40種類。それぞれの大正琴にワイルドカードがあったりする。フローエントリの優先順位にも従わなければならない。面倒。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:17:58exact matchとその他のテーブルを用意した。ツリー構造を作り探索。最終的にプライオリティを見て、正しいフローを選択するようにした。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:20:55リソースの排他アクセス。フローテーブルは圧倒的にread lockが多い。パケットが来る度にlock/unlockしない用にした。単一スレッドで処理できる場合はlockしない。これで2Mfpsまで改善。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:22:19マルチコアを活用して分散処理。8core使って8Mfpsまで改善。コア間の処理の引き継ぎはロックレスノンブロッキングキューを使う。コアを固定してコンテキストスイッチも回避。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:23:46それでも性能が出ない。マッチ処理が重い。対策:フローキャッシュ。マッチしたパケットヘッダの情報をキャッシュする。フローの二つ目以降のパケットは高速処理できる。キャッシュミスすれば通常処理。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:24:44これらの工夫で、Xeon E5-2697 v2 2.7GHzで14.88Mfps(10GbE line rate)を達成した。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:25:38他の課題。論理ポートの対応。configの改良。L2スイッチとのハイブリッド化。性能向上(複数ポートでもline rateを)。現在ソフトウェア処理のみ、ASICなどのハードウェアアクセラレーションも活用 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:27:05ポーリングを行うため。CPU負荷が高い。処理の負荷を減らして仮想化環境でも使えるようにしたい。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:27:33参考: ストラトスフィア、OpenFlow 対応の高速SDNソフトウェアスイッチ「Lagopus」のオープンソース化に際してプロフェッショナルサービスを提供開始 iij.ad.jp/news/pressrele… #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:29:38Q:なぜreadlockが必要なのか?A:read中にフローがなくなると困る。atomicに読むことはできないため。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:30:27Q:Open VSwitchとの違いは? A:Open vSwitchは先駆者。vSwitchを改良することも考えたが、内部構造が複雑すぎた。シンプルなものを作りたかったので、新たに開発し直した。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:31:35マルチコア時代の最新並列並行技術 ~ Haskellから見える世界 ~
IIJ技術研究所 主幹研究員 山本 和彦
本格的にマルチコア時代が到来した今、プログラマにとって並列並行技術は大きな関心事です。プログラムを並列並行化する際には、昔からロックとOSスレッドが使われており、今なお主流であり続けています。この2つの技術は、ほとんどの並列並行プログラムを実現できるほど汎用的ですが、同時に低水準過ぎて間違いを起こしやすく、プログラマを苦しめています。本セッションでは、関数型言語Haskellが提供する最新で高水準で実践的な並列並行技術をご紹介します。
次のセッションは、「マルチコア時代の最新並列並行技術 ~ Haskellから見える世界 ~ IIJ技術研究所 主幹研究員 山本 和彦」です。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:39:16会場へ問いかけ。並列(parallel)と並行(concurrent)の違いは?日本語にすると似た単語、英語だと違う。コンピュータの分野ではこの単語は明確に区別される。 #iij_tw2014 bit.ly/iij_tw2014
2014-11-26 14:41:38