Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Florian Fainelli <f.fainelli@gmail.com>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        "olteanv@gmail.com" <olteanv@gmail.com>,
        "nikolay@nvidia.com" <nikolay@nvidia.com>
Subject: Re: [PATCH net-next v3 1/2] net: dsa: untag the bridge pvid from rx
 skbs
Thread-Topic: [PATCH net-next v3 1/2] net: dsa: untag the bridge pvid from rx
 skbs
Thread-Index: AQHWkfI49n/dW6yWhUaSsyNzEyjVval2wsIAgAAApICAAALZgIAAAXSAgAAAooCAAASgAA==
Date:   Wed, 23 Sep 2020 22:25:22 +0000
Message-ID: <20200923222522.suhyowo4ii3qvvpm@skbuf>
References: <20200923214038.3671566-1-f.fainelli@gmail.com>
 <20200923214038.3671566-2-f.fainelli@gmail.com>
 <20200923214852.x2z5gb6pzaphpfvv@skbuf>
 <7fce7ddd-14a3-8301-d927-1dd4b4431ffb@gmail.com>
 <20200923220121.phnctzovjkiw2qiz@skbuf>
 <c8ca2861-44b2-4333-d63e-638dfe2f06a0@gmail.com>
 <2601834a-2cf2-f0f4-3775-2a5ebccad40a@gmail.com>
In-Reply-To: <2601834a-2cf2-f0f4-3775-2a5ebccad40a@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CA72B6FA2AA1B749966DC82B2D757BC1@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ad19ea2-a503-43c4-e381-08d8600f901e
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 22:25:22.9605
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ++0Ywm/fNV6HbvF9JhycfTmUd1Sn66zsZTIvx4YkBNxYp55A9A2+Qgf8WX9J5KZ++t00hJj90AURRT/7WiHoUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6638
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 23, 2020 at 03:08:49PM -0700, Florian Fainelli wrote:
> On 9/23/20 3:06 PM, Florian Fainelli wrote:
> > On 9/23/20 3:01 PM, Vladimir Oltean wrote:
> >> On Wed, Sep 23, 2020 at 02:51:09PM -0700, Florian Fainelli wrote:
> >>> Speaking of that part of the code, I was also wondering whether you
> >>> wanted this to be netdev_for_each_upper_dev_rcu(br, upper_dev, iter) =
and
> >>> catch a bridge device upper as opposed to a switch port upper? Either
> >>> way is fine and there are possibly use cases for either.
> >>
> >> So, yeah, both use cases are valid, and I did in fact mean uppers of t=
he
> >> bridge, but now that you're raising the point, do we actually support
> >> properly the use case with an 8021q upper of a bridged port? My
> >> understanding is that this VLAN-tagged traffic should not be switched =
on
> >> RX. So without some ACL rule on ingress that the driver must install, =
I
> >> don't see how that can work properly.
> >
> > Is not this a problem only if the DSA master does VLAN receive filterin=
g
> > though?

I don't understand how the DSA master is involved here, sorry.

> > In a bridge with vlan_filtering=3D0 the switch port is supposed to
> > accept any VLAN tagged frames because it does not do ingress VLAN ID
> > checking.
> >
> > Prior to your patch, I would always install a br0.1 upper to pop the
> > default_pvid and that would work fine because the underlying DSA master
> > does not do VLAN filtering.

Yes, but on both your Broadcom tags, the VLAN header is shifted to the
right, so the master's hardware parser shouldn't figure out it's looking
at VLAN (unless your master is DSA-aware). So again, I don't see how
that makes a difference.

>
> This is kind of a bad example, because the switch port has been added to
> the default_pvid VLAN entry, but I believe the rest to be correct though.

I don't think it's a bad example, and I think that we should try to keep
br0.1 working.

Given the fact that all skbs are received as VLAN-tagged, the
dsa_untag_bridge_pvid function tries to guess what is the intention of
the user, in order to figure out when it should strip that tag and when
it shouldn't. When there is a swp0.1 upper, it is clear (to me, at
least) that the intention of the user is to terminate some traffic on
it, so the VLAN tag should be kept. Same should apply to br0.1. The only
difference is that swp0.1 might not work correctly today due to other,
unrelated reasons (like I said, the 8021q upper should 'steal' traffic
from the bridge inside the actual hardware datapath, but without
explicit configuration, which we don't have, it isn't really doing
that). Lastly, in absence of any 8021q upper, the function should untag
the skb to allow VLAN-unaware networking to be performed through the
bridge, because, presumably, that VLAN was added only as a side effect
of driver internal configuration, and is not desirable to any upper
layer.=