From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration Date: Thu, 30 Jun 2011 11:53:50 -0700 Message-ID: <4E0CC63E.3090807@candelatech.com> References: <1309447009-8898-1-git-send-email-jpirko@redhat.com> <4E0CBCE7.4060403@candelatech.com> <20110630182855.GD2056@minipsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net, shemminger@linux-foundation.org, kaber@trash.net, fubar@us.ibm.com, eric.dumazet@gmail.com, nicolas.2p.debian@gmail.com, andy@greyhouse.net To: Jiri Pirko Return-path: Received: from mail.candelatech.com ([208.74.158.172]:46573 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752926Ab1F3SyE (ORCPT ); Thu, 30 Jun 2011 14:54:04 -0400 In-Reply-To: <20110630182855.GD2056@minipsycho> Sender: netdev-owner@vger.kernel.org List-ID: On 06/30/2011 11:28 AM, Jiri Pirko wrote: > Thu, Jun 30, 2011 at 08:13:59PM CEST, greearb@candelatech.com wrote: >> On 06/30/2011 08:16 AM, Jiri Pirko wrote: >>> 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 example >>> 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 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 using per-cpu >>> variables to store port in rx_path (I must check this) >> >>> +enum rx_handler_prio { >>> + RX_HANDLER_PRIO_BRIDGE, >>> + RX_HANDLER_PRIO_BOND, >>> + RX_HANDLER_PRIO_MACVLAN, >>> +}; >> >> Maybe add RX_HANDLER_PRIO_LATER, RX_HANDLER_PRIO_FIRST >> for other modules that want to link >> here, but don't have specific ordering other than before >> or after these specific types? >> >> Or maybe start PRIO_BRIDGE at 100, BOND 110, MACVLAN 120 >> to leave gaps. > > I was thinking about this. But that would be useful only for out of the > tree drivers. For in tree drivers, new prio would be just inserted > whereever. There might be a reason to add a hook at various places, depending on user prefs. I don't know of one now, so it could stay as is and we could change it later if the need came up. I assume this PRIO stuff is purely private to the kernel, so it should be easy to change... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com