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 10:29:16 -0700 Message-ID: <4E0CB26C.9070305@candelatech.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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , netdev@vger.kernel.org, davem@davemloft.net, 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]:58868 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979Ab1F3R3e (ORCPT ); Thu, 30 Jun 2011 13:29:34 -0400 In-Reply-To: <20110630172257.GB2056@minipsycho> Sender: netdev-owner@vger.kernel.org List-ID: On 06/30/2011 10:22 AM, Jiri Pirko wrote: > 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-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) >>> >>> 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 always > 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 these > stupid configs were allowed. It's possible easily to forbid unwanted > configs by checking priv flags. What sorts of stupid things? I didn't look at your patch, but does it handle ordering? In other words, is a bridge logic always handled before VLAN logic? The old hard-coded stuff in dev.c inherently determined ordering. For dynamic handlers, we may need to enforce ordering to give the user any chance of doing things right (it would be very confusing to have the behaviour change completely if you added bridge module before vlan module v/s vlan before bridge). Thanks, Ben > >> > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear Candela Technologies Inc http://www.candelatech.com