From n.nakai ＠ sdy.co.jp Wed Aug 12 11:30:30 2009 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Wed, 12 Aug 2009 11:30:30 +0900 Subject: [Ultramonkey-l7-develop 435] =?iso-2022-jp?b?Q3VycmVudCBzdGF0ZSBvZiBMaW51eCBOZXR3b3JraW5nIA==?= =?iso-2022-jp?b?GyRCJD0kThsoQjI=?= Message-ID: <4A822946.7050000@sdy.co.jp> ■Current state of Linux Networking その2 [FlowDirector] MQの構造は以下のようになっています。 受信時 NICは設定により(EndPointやMACなど)hashしてqueueを確定し処理を行う。 パケットが届いたqueueをドライバが記憶する 送信時 送信するソケットに対して記録されているqueueがあるかを検索 無ければhashを行いqueueを確定する。 ここで問題が発生するのは、一番最初に送信が行われるパターンです。 たとえば、l7vsdの場合でk7vsd->RealServerに接続する場合にMACアドレスで queueを確定してしまうと全て同じqueueを利用しますから意味がありません。そ こで、EndPoint(IP+PORT)を使ってqueueの選択を行うわけですが、TCPサーバへ の通信はサーバがbindしているEndPointに対してアクセスし、acceptした時点で 実際に通信するEndPointが確定するため、listenしているEndPointと、通信が行 われるEndPointは差が生じることになります。 これを回避するには送信したときの情報を受信時に反映させるように出来ればよ いわけで、その仕組みをFlowDirectorと呼び実装が始まっております。 http://kerneltrap.org/mailarchive/linux-netdev/2009/6/5/5875543/thread これは、すでにDavid.S Miller[*1]のgitレポジトリに取り込まれているので、 近くメインラインに入るのは確実でしょう。 l7vsdからFlowDirectorを考察するときにどのようなポイントで注意する必要が あるかは考える必要があると思っています。 [soft receive packet steering:RPS] MultiQueueはNICの段階からパケットを複数のCPUに分離して処理仕様という思想 ですがSoftware receive paclet steering(以下RPS)は、NICがパケットを receiveしたときに慎重に複数のCPUにコピーして、IPI[*2]を使って複数のCPUで パケットの組み立てを処理しようと言うgoogleのパッチです。 http://kerneltrap.org/mailarchive/linux-netdev/2009/4/8/5441724 これはハードウェアで行われているMultiQueueのパケット分離部分をソフトウェ ア的に行うように見えるパッチです。 無論CPUの負荷は全体的に増える傾向にあるものの上記リンクにあるようにNICの 種類に寄らず、向上しているように見てます。 ただし、RPSにおいてCPUトポロジとキャッシュ構造を意識しないと効率よく動か せないように見てます。 と、言うのも4coreチップを4つ、合計16coreとした場合にCPUトポロジ的に見る と近いコアと遠いコアが現れることになります。 隣接する4コアと遠い4コア。CPUの間のコピーするコストと複数のCPUでの処理低 減がどの程度速くなるかと言う問題がありますね。 UltraMonkeyの視点から見るとRPSもどのCPUでどのコネクションの処理を行って いるのかと言う情報が得られ無いとCPUとスレッドをあわせられないと思いま す。現状sysfsではCPUMASKしか存在しないため、CPUトポロジもユーザーが設定 するような構造になっているんでしょう。 (もしくはCPUのトポロジ情報を持つ常駐プロセスがsysfsに書き込むような構造?) [まとめ] 二回にメールが分かれてしまいましたが、今現在10Gbitや40Gbitなどの次世代 ネットワークが立ち上がりつつあり、LinuxのNetwork構造がそれを使い切れない 状況です。 それは、CPU単体の速度向上が今現在止まってしまっており、ハードウェアで解 決する方法がMultiQueueであり、GoogleのRPSのようなソフトウェア的な実装も ありますが、どのように複数のCPUで分散して処理を行うかと言うのがメインの 話題になっていました。 そこでl7vsdのようなユーザー空間で動くアプリケーションを見た場合には矢張 りマルチCPUを意識する必要があると思います。 かつ、connectionとCPUがそれぞれペアを組むとしたなばら、もはやsingle threadでは意味をなさず、かつmulti threadであってもworker threadのような 単純にマルチに動くようなアプリケーションではなく、1thread : 1connection と言うようなコネクションあたり1cpuを利用するような構造にする必要があると 感じました。 これはそのまま、「The Free Lunch Is Orver」であって、ユーザー空間であれ やはりCPUが進化していけばそのままの構造で速くなると言う時代は終了したと いうのを強く印象づけられました。 このことから次期UltraMonkeyは1thread : 1connectionとした場合にMQやRPS、 FlowDirectorにマッチングする構造はどのような物なのか、そしてそれらを有効 活用するにはどのような情報をkernelから受け取られればいいのかを考察する必 要があります。 ここは次期UltraMonkey構造のメールスレッドを起こしますので、積極的に議論 できればよいかと思います。 (他にもOLSの話は別途メールを投げます) OLSの話としては10GbitTuningとリアルタイムプロセスの話を次回にしますね。 [*1] David.S Miller RedHatに所属するLinuxのネットワークメンテナ。 http://vger.kernel.org/~davem/ [*2] IPI(Inter Processor Interrupt) CPUに内蔵されるlocalAPICのこと。マルチプロセッサによる割り込みを利用した CPU間通信。 -- _____________________________________________ 中居 憲久[Norihisa NAKAI] n.nakai ＠ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From takebayashi.shinya ＠ oss.ntt.co.jp Wed Aug 12 11:30:52 2009 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Wed, 12 Aug 2009 11:30:52 +0900 Subject: [Ultramonkey-l7-develop 436] Re: =?iso-2022-jp?b?GyRCJD0kbSQ9JG0laiVqITwlOSQ3JF4kOyRzJCsbKEI=?= In-Reply-To: <20090805.163754.575506240427252779.tateishi.katsuyuki@oss.ntt.co.jp> References: <20090805.163754.575506240427252779.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: 竹林です． man-fix ブランチの作業が終わりました． まだ releng ブランチにマージしていないので，リリースファイルを 作成する際には忘れないようにお願い致します． > また、フリーズ前までに各ブランチごとに > ・変更点のサマリ（2.1.2-3用 CHANGES に記載するための元ネタ） > ・リリース前検証用の確認項目 > を -develop に投げてもらえるとうれしいです。 変更点は，man ページのアップデートと，インストールパスの変更です． インストールパスの設定については autotools の方で対応していると 思いますので，Makefile.am に dist_man_MANS = l7vsd.8 l7vsadm.8 l7directord.8 のみ設定しています． > あと modulefix, sslid-sslidlength-refine の変更ファイルがかぶっ > てるので、関係者の方は注意してください。 こちらは OK でした． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From takebayashi.shinya ＠ oss.ntt.co.jp Wed Aug 12 14:51:36 2009 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Wed, 12 Aug 2009 14:51:36 +0900 Subject: [Ultramonkey-l7-develop 437] Re: =?iso-2022-jp?b?GyRCJD0kbSQ9JG0laiVqITwlOSQ3JF4kOyRzJCsbKEI=?= In-Reply-To: <20090805.164600.57809164276625453.tateishi.katsuyuki@oss.ntt.co.jp> References: <20090805.164600.57809164276625453.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: 立石 さま 竹林です． gcc 4.3 に対応したコードへのパッチを当てたブランチを作りました． debian lenny などでビルドできない事象への対処です． パッチを当てた版でも RHEL 系でビルドできることは確認済みです． できれば，こちらもマージ願います． TATEISHI Katsuyuki wrote in message < 20090805.164600.57809164276625453.tateishi.katsuyuki ＠ oss.ntt.co.jp> *** Subject: [Ultramonkey-l7-develop 425] Re: そろそろリリースしませんか *** Date: 2009/08/05 16:46:00 > 立石です。 > > From: Shinya TAKEBAYASHI > Subject: [Ultramonkey-l7-develop 423] Re: そろそろリリースしませんか > Date: Wed, 05 Aug 2009 16:27:44 +0900 > > > sslproxy にも X-Fowarded-For を付加するパッチが当たったブランチが > > ありましたので，こちらも併せてリリースしても良いかと思います． > > 了解です。 > これも他のブランチと同様 > ・変更点サマリ (CHANGES用) > ・確認ポイント (リリース前検証用) > を -develop までお願いします ＞ 田沼さん? > > ・・・sslproxy も Autotools まわりで ultramonkey-l7-v2 と同様 > の制限がありそうです。心が折れなければ autotools-fix ブランチ > を切って修正しときます。 > > -- > TATEISHI Katsuyuki > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From n.nakai ＠ sdy.co.jp Wed Aug 12 14:56:36 2009 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Wed, 12 Aug 2009 14:56:36 +0900 Subject: [Ultramonkey-l7-develop 438] [OLS2009]Tuning 10Gb network cards on Linux Message-ID: <4A825994.7030505@sdy.co.jp> ■Tuning 10Gb network cards on Linux 前回のメールでもあるように高速化するNetworkに今のCPUでは対応出来ない状況 にありますから、少しでも速度を出すにはどのようにするのかと言うのは重要な 部分です。 基本的にSE的な範疇はこちらの部分が多いかと思います。 具体的には 1) TOE[*1]にてハードウェアオフロード出来る部分はオフロードを行いCPU使用 率を少なくする ・checksumをNICにやらせるようにする ・DMAを使って分散されたメモリ領域コピーを行いAPIのコストを下げる ・(TCPやその他)segmantation checkをNICにやらせるようにする 2) 転送レートの調整 ・信頼性のあるネットワークではエラー訂正を省略して帯域を稼ぐ ・最適な輻輳制御アルゴリズムを用いる ・TCPパケットのウィンドウサイズを最適化する 3) TCPバッファを最適化する ・queueサイズの最適化 ・受信ソケットバッファサイズの最適化 のカテゴリごとにethtoolで設定するものやkernelパラメーターで設定する物が あります。 これらを一意に整理することは難しいので(例えばqueue関係だとNICからのDMAで の書き込みが関連するのでethtoolsでNICに対してダイレクトに設定する必要と kernelに対して設定する必要が生じるためsysfsの設定も絡む)、理解しづらいと は思いますが思想的には上の3つになります。 1)はMultiQueueと同じ思想でなるべく専用ハードウェアにやらせようと言う思想 であり2)は10Gbになって速度を達成する状況が厳しい環境だと速度を上げたり下 げたりする必要が出てくるためなるべく下げない、かつあがりやすい環境設定が どのような物かと言う解説になります。3)は1Gbでも出てきた話であり、バッ ファを10Gbでどのように設定するかという話ですね。 基本的にUltraMonkey-L7のコードに直接絡んでくる話はありませんが、速度検証 などを行うときにこれらの条件をちゃんと確認して、不意な速度低下を引き出さ ないようにノウハウをまとめておくことが大事かと思います。 直接具体的な値に関してはproceedingを参照してもらうこととして、「チューニ ングで考察する部分がうなぎ登りに多くなっている」と言うのは率直な感想で しょうか。 どんどん高度化するネットワークに関して、どんどん技術者に要求されるスキル は上がってきているなと思いました(苦笑 [*1]TOE TCP/IP Offload Engine デフォルトではOFFになっているので、ethtoolを使って設定を行う -- _____________________________________________ 中居 憲久[Norihisa NAKAI] n.nakai ＠ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From kt ＠ wheel.jp Wed Aug 12 15:25:06 2009 From: kt ＠ wheel.jp (TATEISHI Katsuyuki) Date: Wed, 12 Aug 2009 15:25:06 +0900 (JST) Subject: [Ultramonkey-l7-develop 439] Re: =?iso-2022-jp?b?GyRCJD0kbSQ9JG0laiVqITwlOSQ3JF4kOyRzJCsbKEI=?= In-Reply-To: References: <20090805.163754.575506240427252779.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <20090812.152506.75173119342941020.kt@wheel.jp> 立石です。 From: Shinya TAKEBAYASHI Subject: [Ultramonkey-l7-develop 436] Re: そろそろリリースしませんか Date: Wed, 12 Aug 2009 11:30:52 +0900 > まだ releng ブランチにマージしていないので，リリースファイルを > 作成する際には忘れないようにお願い致します． 了解です。 >> あと modulefix, sslid-sslidlength-refine の変更ファイルがかぶっ >> てるので、関係者の方は注意してください。 > > こちらは OK でした． ありがとうございます。 -- TATEISHI Katsuyuki From kt ＠ wheel.jp Wed Aug 12 15:25:43 2009 From: kt ＠ wheel.jp (TATEISHI Katsuyuki) Date: Wed, 12 Aug 2009 15:25:43 +0900 (JST) Subject: [Ultramonkey-l7-develop 440] Re: =?iso-2022-jp?b?GyRCJD0kbSQ9JG0laiVqITwlOSQ3JF4kOyRzJCsbKEI=?= In-Reply-To: References: <20090805.164600.57809164276625453.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <20090812.152543.632868946524006272.kt@wheel.jp> 立石です。 From: Shinya TAKEBAYASHI Subject: [Ultramonkey-l7-develop 437] Re: そろそろリリースしませんか Date: Wed, 12 Aug 2009 14:51:36 +0900 > gcc 4.3 に対応したコードへのパッチを当てたブランチを作りました． > debian lenny などでビルドできない事象への対処です． > パッチを当てた版でも RHEL 系でビルドできることは確認済みです． > > できれば，こちらもマージ願います． 了解しました。 -- TATEISHI Katsuyuki From takebayashi.shinya ＠ oss.ntt.co.jp Wed Aug 12 16:58:10 2009 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Wed, 12 Aug 2009 16:58:10 +0900 Subject: [Ultramonkey-l7-develop 441] =?iso-2022-jp?b?ZGViaWFuIBskQiVHJSMlbCUvJUglaiRLJEQkJCRGGyhC?= Message-ID: 立石 さま 竹林です． Debian 用 deb パッケージを作るために用意している debian ディレクトリについて整理を進めているところですが， どうもパッケージ名の付け方がイケていなくて dpkg helper が動いてくれません． 強引にディレクトリ名を変えたりすれば，何とか通すことは出来ますが， 美しくありません． 現行のバージョン番号： ultramonkey-l7-2.1.3-0 dpkg helper が許容するバージョン番号： ultramonkeyl7-2.1.3 ※ packagename-version となっている必要があるので，packagename に ハイフンが入っていると具合が悪いのです という訳で，ultramonkey-l7-2.x.x 系では deb パッケージへの対応は 止めにして，v3 以降で対応したいと思いますので，今回のリリース以降は debian ディレクトリを削除していただけますか． また，並行して新しいパッケージ名・バージョン番号の付与基準について 議論する必要があると考えますので，ご協力お願いします． ＃ 近いうちに頭出しします 参考として，以前バージョン番号について議論したときの スレッドへのポインタを入れておきます． *** Sender: Shinya TAKEBAYASHI *** MsgID: Jx3wVUPw_2SFCaBEhgYycbTQ1 ＠ oss.ntt.co.jp *** Subject: [Ultramonkey-l7-develop 400] バージョン番号フォーマットの変更につい て *** Date: 2009/06/23 8:07:00 ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From kt ＠ wheel.jp Wed Aug 12 17:53:23 2009 From: kt ＠ wheel.jp (TATEISHI Katsuyuki) Date: Wed, 12 Aug 2009 17:53:23 +0900 (JST) Subject: [Ultramonkey-l7-develop 442] Re: =?iso-2022-jp?b?ZGViaWFuIBskQiVHJSMlbCUvJUglaiRLJEQkJCRGGyhC?= In-Reply-To: References: Message-ID: <20090812.175323.75173119879809692.kt@wheel.jp> 立石です。 From: Shinya TAKEBAYASHI Subject: [Ultramonkey-l7-develop 441] debian ディレクトリについて Date: Wed, 12 Aug 2009 16:58:10 +0900 > Debian 用 deb パッケージを作るために用意している > debian ディレクトリについて整理を進めているところですが， > どうもパッケージ名の付け方がイケていなくて dpkg helper が動いてくれません． > > 強引にディレクトリ名を変えたりすれば，何とか通すことは出来ますが， > 美しくありません． > > 現行のバージョン番号： ultramonkey-l7-2.1.3-0 > dpkg helper が許容するバージョン番号： ultramonkeyl7-2.1.3 > > ※ packagename-version となっている必要があるので，packagename に > ハイフンが入っていると具合が悪いのです ハイフンは鬼門ですね。 最後の -0 も RPM で付与するだけにしたほうがよさそうですね。 ちなみにディストリビューションによっては大文字も非推奨かもし れないです。(ultramonkeyL7 とかはやめた方が良さげ) > という訳で，ultramonkey-l7-2.x.x 系では deb パッケージへの対応は > 止めにして，v3 以降で対応したいと思いますので，今回のリリース以降は > debian ディレクトリを削除していただけますか． 現状でも動いてないはずなので、debian ディレクトリは削除という ことで了解です。その他(パッケージ名、バージョン番号)は現状維 持ということで。 > また，並行して新しいパッケージ名・バージョン番号の付与基準について > 議論する必要があると考えますので，ご協力お願いします． > ＃ 近いうちに頭出しします 了解です。 ちょっと別の話になっちゃいますが、v3では設定ファイルの場所と かプロトコルモジュールのインストール先とかも整理したいところ です。 -- TATEISHI Katsuyuki From kt ＠ wheel.jp Wed Aug 12 18:23:16 2009 From: kt ＠ wheel.jp (TATEISHI Katsuyuki) Date: Wed, 12 Aug 2009 18:23:16 +0900 (JST) Subject: [Ultramonkey-l7-develop 443] =?iso-2022-jp?b?UkMbJEIlVSUhJSQlayROQ1YkLT5sPWobKEI=?= Message-ID: <20090812.182316.632868945852918309.kt@wheel.jp> 竹林さん、 立石です。お疲れさまです。 RCのアーカイブファイルを置く場所を探しているのですが、適切な 場所ってありますか？ 以前は公式サイトの下にディレクトリがあったような気がしますが、 現在は Geeklog が置いてあるので、直接ディレクトリを切るのはた めらわれます。 公式サイト直下でよければ、Geeklog 的に安全なディレクトリ名を 教えてください。(or Geeklog にファイルのアップロード機能があ ればそっちのほうがいいかも) すぐには対応が難しいようであれば、こちらで外部に用意します。 -- TATEISHI Katsuyuki