Re: [Bridge] [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

On Fri, May 25, 2018 at 01:09:46PM +0300, Petr Machata wrote:
> Florian Fainelli <f.fainelli@gmail.com> writes:
> 
> > You seem to have approached the bridge changes a little differently from
> > this series:
> >
> > https://lists.linux-foundation.org/pipermail/bridge/2016-November/010112.html
> 
> It pretty much extends the patchset to also send the notifications for
> the CPU port.
> 
> I missed this e-mail yesterday and now I see you already found out for
> yourself how it behaves.
> 
> > Both have the same intent that by targeting the bridge device itself,
> > you can propagate that through switchdev to the switch drivers, and in
> > turn create configurations where for instance, you have:
> >
> > - CPU/management port present in specific VLANs that is a subset or
> > superset of the VLANs configured on front-panel ports
> > - CPU/management port tagged/untagged in specific VLANs which can be a
> > different setting from the front-panel ports
> >
> > One problem we have in DSA at the moment is that we always add the CPU
> > port to the VLANs configured to the front-panel port but we do this with
> > the same attributes as the front panel ports! For instance, if you add
> > Port 0 to VLAN1 untagged, the the CPU port also gets added to that
> > VLAN1, also untagged. As long as there is just one VLAN untagged, this
> > is not much of a problem. Now do this with another VLAN or another port,
> > and the CPU can no longer differentiate the traffic from which VLAN it
> > is coming from, no bueno.
> 
> Yep, with this patchset you should be able to use the CPU port
> notifications to configure things exactly.
> 
> > bridge vlan add vid 2 dev port0 pvid untagged
> > 	-> port0 (e.g: switch port 0) gets programmed
> > 	-> CPU port gets programmed
> > bridge vlan add vid 2 dev br0 self
> > 	-> CPU port gets programmed
> > bridge vlan add vid 2 dev port0
> > 	-> port0 (switch port 0) gets programmed
> >
> > Are these use cases possible with your series? It seems to me like it is
> > if we drop the netif_is_bridge_master() checks and resolve orig_dev as
> > being a hint for the CPU/management port.
> 
> Yeah, that's how it behaves. If you accept the events where
> netif_is_bridge_master(orig_dev), you can tell the CPU port-related
> events from the rest by BRIDGE_VLAN_INFO_BRENTRY.
This also addresses the issue i am having trying to add switchdev functionality
to a driver that needs separate configuration for cpu port.  
https://www.spinics.net/lists/netdev/msg504577.html

Tested it and it works fine

Thanks,
Ilias