Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration

From: Ben Greear <[email-masked]>
Date: Thu, 30 Jun 2011 10:29:16 -0700

On 06/30/2011 10:22 AM, Jiri Pirko wrote:
> Thu, Jun 30, 2011 at 06:27:12PM CEST, [email-masked] wrote:
>> On Thu, 30 Jun 2011 17:16:49 +0200
>> Jiri Pirko<[email-masked]>  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<[email-masked]>
>>
>> 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 [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Greear <[email-masked]>
Candela Technologies Inc  http://www.candelatech.com