2011/6/30 Jiri Pirko [off-list ref]:

Thu, Jun 30, 2011 at 06:27:12PM CEST, shemminger@vyatta.com wrote:

quoted

On Thu, 30 Jun 2011 17:16:49 +0200
Jiri Pirko [off-list ref] wrote:

quoted

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 <redacted>

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).

quoted

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.

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. ;-)

Best Regards,
Michał Mirosław