From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration Date: Fri, 01 Jul 2011 16:57:07 +0200 Message-ID: <4E0DE043.4030701@gmail.com> References: <1309447009-8898-1-git-send-email-jpirko@redhat.com> <20110630092712.17eb292f@nehalam.ftrdhcpuser.net> <20110630172257.GB2056@minipsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jiri Pirko , Stephen Hemminger , netdev@vger.kernel.org, davem@davemloft.net, kaber@trash.net, fubar@us.ibm.com, eric.dumazet@gmail.com, andy@greyhouse.net To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Return-path: Received: from mail-fx0-f52.google.com ([209.85.161.52]:44681 "EHLO mail-fx0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708Ab1GAO5L (ORCPT ); Fri, 1 Jul 2011 10:57:11 -0400 Received: by fxd18 with SMTP id 18so3359629fxd.11 for ; Fri, 01 Jul 2011 07:57:10 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Le 01/07/2011 08:36, Micha=C5=82 Miros=C5=82aw a =C3=A9crit : > 2011/6/30 Jiri Pirko: >> Thu, Jun 30, 2011 at 06:27:12PM CEST, shemminger@vyatta.com wrote: >>> On Thu, 30 Jun 2011 17:16:49 +0200 >>> Jiri Pirko wrote: >>> >>>> For some net topos it is necessary to have multiple "soft-net-devi= ces" >>>> hooked on one netdev. For example very common is to have >>>> eth<->(br+vlan). Vlan is not using rh_handler (yet) but also for e= xample >>>> macvlan would be useful to have hooked on same netdev as br. >>>> >>>> This patch introduces rx_handler list. size struct net_device stay= s >>>> intact. Measured performance regression on eth-br topo is ~1% (on = received >>>> 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 us= ing per-cpu >>>> variables to store port in rx_path (I must check this) >>>> >>>> Please comment. >>>> >>>> Signed-off-by: Jiri Pirko >>> >>> I am ok with the infrastructure, but why should Vlan use rh_handle. >> >> Well why it shoudln't. It would fit into what rx_handler is here for= - the >> code would be more unified. Also net_device struct would lose struct >> vlan_group __rcu *vlgrp pointer (and reducing net_device size is alw= ays >> good thing). >> >>> It is wrong to allow macvlan and bridge to share same device. >>> Right now the code blocks users from doing lots of stupid things. >> >> Right, this is since rx_handler was introduced. Before that all thes= e >> stupid configs were allowed. It's possible easily to forbid unwanted >> configs by checking priv flags. > > We could introduce a catch-all macvlan/vlan device that would take > addresses/VLANs which are not covered by other configured > macvlans/vlans. This would allow clearer configuration and would make > the evaluation order explicit. As a bonus, this will give another > device to put tcpdump on. ;-) 'Sounds like what I had in mind in http://marc.info/?l=3Dlinux-netdev&m= =3D130622112921245&w=3D2 . Nicolas.