From omoikanenomikoto ＠ gmail.com Wed Oct 14 09:53:28 2009 From: omoikanenomikoto ＠ gmail.com (Shinya TAKEBAYASHI) Date: Wed, 14 Oct 2009 09:53:28 +0900 Subject: [Ultramonkey-l7-develop 542] Re: =?iso-2022-jp?b?RGFpdmQbJEIkSCROT0MkNzlnJCQkSyREJCQkRhsoQg==?= In-Reply-To: <4ACA14FD.2010800@sdy.co.jp> References: <4AC62ADA.8010808@sdy.co.jp> <4AC942B3.8060706@sdy.co.jp> <4AC9960F.5000000@iwao.net> <4ACA14FD.2010800@sdy.co.jp> Message-ID: 竹林です． だーいぶ乗り遅れています． すみません． > > Direct FlowやDirect Acceptに対応していないカード、ドライバだとまた > > アプリの作りに影響はするんですが、そこはカーネル側でDirect Acceptを > > ソフト的にエミュレートしたほうがいい気がします。 > > エミュレートを考察してみると…、 > 例えば、MQぢゃないカードが入っているかどうか?かた始まれば、 > まず第一にMQのON/OFFは必要かとおもいます。 > #コードをスイッチする必要がありますから。 > あと、OSがどこまでサポートしているか判定する基準がほしいですよね。 エミュレートするののは， ○ DirectAccept に対応していない環境でも，ユーザ空間の アプリケーションには同機能が使えるように見せる ということですよね． 既存のコードは既存のコードのままで使えるし，複数スレッドから accept を 発行するようなアプリケーションには DirectAccept を使えるように カーネル側が対応する，ということで． そうなると，アプリケーション側でコードをスイッチする必要はなくて もし MQ が使えない環境であれば，カーネル側で DirectAccept を 吸収する（内部でシリアライズする？）ようにするという理解です． 中居さんの提案する MQ の ON/OFF は，OS として MQ の機能を生かす・殺すの 切り替えができるようにする必要がある，ということでしょうか． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: omoikanenomikoto ＠ gmail.com GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From makoto ＠ kanon-net.jp Wed Oct 14 12:05:20 2009 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Wed, 14 Oct 2009 12:05:20 +0900 Subject: [Ultramonkey-l7-develop 543] Re: =?iso-2022-jp?b?RGFpdmQbJEIkSCROT0MkNzlnJCQkSyREJCQkRhsoQg==?= In-Reply-To: <4ACA14FD.2010800@sdy.co.jp> References: <4AC62ADA.8010808@sdy.co.jp> <4AC942B3.8060706@sdy.co.jp> <4AC9960F.5000000@iwao.net> <4ACA14FD.2010800@sdy.co.jp> Message-ID: 竹林です． だーいぶ乗り遅れています． すみません． > > Direct FlowやDirect Acceptに対応していないカード、ドライバだとまた > > アプリの作りに影響はするんですが、そこはカーネル側でDirect Acceptを > > ソフト的にエミュレートしたほうがいい気がします。 > > エミュレートを考察してみると…、 > 例えば、MQぢゃないカードが入っているかどうか?かた始まれば、 > まず第一にMQのON/OFFは必要かとおもいます。 > #コードをスイッチする必要がありますから。 > あと、OSがどこまでサポートしているか判定する基準がほしいですよね。 エミュレートするののは， ○ DirectAccept に対応していない環境でも，ユーザ空間の アプリケーションには同機能が使えるように見せる ということですよね． 既存のコードは既存のコードのままで使えるし，複数スレッドから accept を 発行するようなアプリケーションには DirectAccept を使えるように カーネル側が対応する，ということで． そうなると，アプリケーション側でコードをスイッチする必要はなくて もし MQ が使えない環境であれば，カーネル側で DirectAccept を 吸収する（内部でシリアライズする？）ようにするという理解です． 中居さんの提案する MQ の ON/OFF は，OS として MQ の機能を生かす・殺すの 切り替えができるようにする必要がある，ということでしょうか． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: makoto ＠ kanon-net.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From h-nakano ＠ iwao.net Wed Oct 14 17:19:47 2009 From: h-nakano ＠ iwao.net (=?ISO-2022-JP?B?GyRCQ2ZMbjkoTy8bKEI=?=) Date: Wed, 14 Oct 2009 17:19:47 +0900 Subject: [Ultramonkey-l7-develop 544] [Fwd: NFQUEUE] Message-ID: 中野@たるすぴです。 お疲れっす。 フェルナンドさんからこれを朝に教えてもらっていたのを忘れてました。 新しいMQ活用方法です。 これでMultiQueueの活用方式としては現在、 ・Qdisc ・FlowDirector(Multi Accept) ・NFQUEUE ・RPS の4つかな(汗) そして、GoogleはRPSにFlowDirectorエミュレーションを 取り込もうとしている、と。 Devideとの会談の前に把握しとかねば。 ちなみにHerbert Xuも来るそうです。 -------- Original Message -------- Subject: NFQUEUE Date: Wed, 14 Oct 2009 08:57:28 +0900 From: Fernando Luis Vázquez Cao To: NAKANO Hiroaki commit 10662aa3083f869c645cc2abf5d66849001e2f5d Author: Florian Westphal Date: Fri Jun 5 13:24:24 2009 +0200 netfilter: xt_NFQUEUE: queue balancing support Adds support for specifying a range of queues instead of a single queue id. Flows will be distributed across the given range. This is useful for multicore systems: Instead of having a single application read packets from a queue, start multiple instances on queues x, x+1, .. x+n. Each instance can process flows independently. Packets for the same connection are put into the same queue. Signed-off-by: Holger Eitzenberger Signed-off-by: Florian Westphal Signed-off-by: Patrick McHardy commit 61f5abcab152cbee3a041f8b9bcfe7afc83409ca Author: Florian Westphal Date: Fri Jun 5 13:18:07 2009 +0200 netfilter: xt_NFQUEUE: use NFPROTO_UNSPEC We can use wildcard matching here, just like ab4f21e6fb1c09b13c4c3cb8357babe8223471bd ("xtables: use NFPROTO_UNSPEC in more extensions"). Signed-off-by: Florian Westphal Signed-off-by: Patrick McHardy