netdev - Re: [RFC patch net-next-2.6] net: allow multiple rx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Jun 2011 10:29:16 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Jiri Pirko <jpirko@...hat.com>
CC:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org,
	davem@...emloft.net, kaber@...sh.net, fubar@...ibm.com,
	eric.dumazet@...il.com, nicolas.2p.debian@...il.com,
	andy@...yhouse.net
Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration

On 06/30/2011 10:22 AM, Jiri Pirko wrote:
> Thu, Jun 30, 2011 at 06:27:12PM CEST, shemminger@...tta.com wrote:
>> On Thu, 30 Jun 2011 17:16:49 +0200
>> Jiri Pirko<jpirko@...hat.com>  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<jpirko@...hat.com>
>>
>> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html