From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration Date: Fri, 1 Jul 2011 07:45:38 +0200 Message-ID: <20110701054537.GC2075@minipsycho> References: <1309447009-8898-1-git-send-email-jpirko@redhat.com> <4E0CD39C.8060209@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: netdev@vger.kernel.org, davem@davemloft.net, shemminger@linux-foundation.org, kaber@trash.net, fubar@us.ibm.com, eric.dumazet@gmail.com, andy@greyhouse.net, Ben Greear To: Nicolas de =?iso-8859-1?Q?Peslo=FCan?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60998 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752604Ab1GAFpv (ORCPT ); Fri, 1 Jul 2011 01:45:51 -0400 Content-Disposition: inline In-Reply-To: <4E0CD39C.8060209@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Jun 30, 2011 at 09:50:52PM CEST, nicolas.2p.debian@gmail.com wrote= : >Le 30/06/2011 17:16, Jiri Pirko a =E9crit : >>For some net topos it is necessary to have multiple "soft-net-devices= " >>hooked on one netdev. For example very common is to have >>eth<->(br+vlan). Vlan is not using rh_handler (yet) but also for exam= ple >>macvlan would be useful to have hooked on same netdev as br. >> >>This patch introduces rx_handler list. size struct net_device stays >>intact. Measured performance regression on eth-br topo is ~1% (on rec= eived >>pkts generated by pktgen) and on eth-bond topo it is ~0.25% >> >>On br I think that the performance can be brought back maybe by using= per-cpu >>variables to store port in rx_path (I must check this) >> >>Please comment. >> >>Signed-off-by: Jiri Pirko > >I like the idea of this patch. > >I didn't take time for a technical review yet, but I'm not sure >ordering should be static, depending on the kind of device (bond, br, >macvlan). Ordering is currently static, because it is hard coded. > >I think rx_handler_prio should be exposed to userspace, to allow user >setup to decide the exact order. Default order should be safe, but >user should be allowed to force a different order for special setups. Hmm I didn't think about this. Not sure about the right way how to expo= se this. > > Nicolas.