From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilias Apalodimas Subject: Re: [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs Date: Fri, 25 May 2018 15:33:49 +0300 Message-ID: <20180525123348.GA15604@apalos> References: <61962919-cf93-cd7b-f248-9dfee5c9529d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Fainelli , netdev@vger.kernel.org, devel@driverdev.osuosl.org, bridge@lists.linux-foundation.org, jiri@mellanox.com, idosch@mellanox.com, davem@davemloft.net, razvan.stefanescu@nxp.com, gregkh@linuxfoundation.org, stephen@networkplumber.org, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, nikolay@cumulusnetworks.com To: Petr Machata Return-path: Received: from mail-wr0-f193.google.com ([209.85.128.193]:37767 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932994AbeEYMdy (ORCPT ); Fri, 25 May 2018 08:33:54 -0400 Received: by mail-wr0-f193.google.com with SMTP id i12-v6so8978227wrc.4 for ; Fri, 25 May 2018 05:33:53 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Fri, May 25, 2018 at 01:09:46PM +0300, Petr Machata wrote: > Florian Fainelli 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