Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Ioana Ciornei <ioana.ciornei@nxp.com>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: RE: [PATCH 06/12] staging: dpaa2-ethsw: add ACL entry to redirect STP
 to CPU
Thread-Topic: [PATCH 06/12] staging: dpaa2-ethsw: add ACL entry to redirect
 STP to CPU
Thread-Index: AQHVk9VwUttQp4rnGEyeNWyFfbjmDKd8oR0AgAAAhWCAABrTAIABX2xAgAAfjgCAAAVHsA==
Date:   Wed, 6 Nov 2019 15:22:30 +0000
Message-ID: <DB6PR0402MB27896E3229CC3397F26122EAE0790@DB6PR0402MB2789.eurprd04.prod.outlook.com>
References: <1572957275-23383-1-git-send-email-ioana.ciornei@nxp.com>
 <1572957275-23383-7-git-send-email-ioana.ciornei@nxp.com>
 <20191105142202.GC7189@lunn.ch>
 <VI1PR0402MB28007254BB7614477CED4DBCE07E0@VI1PR0402MB2800.eurprd04.prod.outlook.com>
 <20191105155954.GE17620@lunn.ch>
 <DB6PR0402MB27899B298481E7A3460BB9BFE0790@DB6PR0402MB2789.eurprd04.prod.outlook.com>
 <20191106145038.GB30762@lunn.ch>
In-Reply-To: <20191106145038.GB30762@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ed0293e-94df-46bc-6b1b-08d762cd2434
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 15:22:30.8428
 (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: LcH5maa+cOntm2TCIkPKyaQy5Tr3nDjCBMW3FZXaKK8jG1vqYEdCIYOb0rdnoeDzeLdC4IJ9I7IQmHHbWNki8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2805
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: Re: [PATCH 06/12] staging: dpaa2-ethsw: add ACL entry to redirec=
t
> STP to CPU
>=20
> On Wed, Nov 06, 2019 at 01:47:47PM +0000, Ioana Ciornei wrote:
> > > Subject: Re: [PATCH 06/12] staging: dpaa2-ethsw: add ACL entry to
> > > redirect STP to CPU
> > >
> > > > The control queues do not form an actual interface in the sense
> > > > that the CPU does not receive unknown unicast, broadcast and
> > > > multicast frames by default.  For each frame that we want to
> > > > direct to the CPU we must add an ACL entry.
> > >
> > > So this appears to be one of the dumbest switches so far :-(
> >
> > To be fair, the actual hardware can do much more.
> > The problem here is that the firmware models the switch in a non-Linux
> style.
>=20
> Well, the whole hardware is not very linux like!

Well, that's a pretty good description of what I am dealing with here.

>=20
> > >
> > > Can you add an ACL which is all L2 broadcast/multicast?  That would
> > > be a good first step.
> >
> > I can add that but it would not be enough.
> > For example, unknown unicast would not be matched thus would not
> reach the CPU.
>=20
> Not ideal, but you could rely on ARP and ND. Any conversation should star=
t
> with a broadcast/multicast ARP or ND. The bridge should add an FDB based
> on what it just learned, and traffic should flow. And when the interface =
is not
> part of a bridge, you don't care about unknown unicast.

If I do this, I would have an L2 switch that relies on IP traffic passing t=
hrough it.
Also, if I use ACLs to model dynamic FDB entries than I will need to "softw=
are age
the ACLs... which is at least not ideal.

>=20
> > > Does the ACL stop further processing of the frame? Ideally you want
> > > the switch to also flood broadcast/multicast out other ports, if
> > > they are in a bridge. If it cannot, you end up with the software brid=
ge
> doing the flooding.
> >
> > Yes, the ACL stops any further processing.
>=20
> O.K, the software bridge can handle that. It is not the best use for hard=
ware,
> but will work.
>=20
> > Your assumption is true, learning, with the current implementation, is =
not
> possible for CPU frames.
> > In .ndo_start_xmit() we inject directly into the switch port's Tx queue=
s,
> thus bypassing the entire learning process.
> >
> > All in all, I do not see a way out just by using the ACL mechanism (bec=
ause
> of unknown unicast frames).
> >
> > I have to talk in detail with the firmware team, but from what I can
> understand if we make the following changes in firmware it would better f=
it
> the Linux framework:
> >  * make the CPU receive unknown unicast, broadcast and multicast
> > frames by default (without any ACLs)
>=20
> Yes, that is the first step. Some switches go further. Link local L2 fram=
es are
> always passed to the CPU. All ARP and ND packets are passed, IGMP, etc.
> Once you have the first step working, you start thinking about the next s=
tep.
> That is blocking some of this traffic hitting the CPU. IGMP snooping is o=
ne
> way. You need to continue receiving the IGMP frames, but not the multicas=
t
> traffic. But they use the same MAC address. So the switch needs to look
> deeper into the packet.
>=20
> > * frames originated on the CPU should not bypass the learning
> >   process (it should have its own Tx queues that go through the
> >   same learning process)
>=20
> Learning is needed. But maybe not its own Tx queue. It depends on the QoS
> architecture. Ideally you want QoS to work on CPU frames, so they get put
> into the correct egress queue for there QoS level.
>=20
> With DSA this is simpler, since you have a physical interface connected t=
o the
> CPU, so you can use that interface number in all your tables. But with a =
pure
> switchdev driver, each port effectively becomes two ports, one to the fro=
nt
> panel and one to the CPU port. And your tables need to differentiate this=
.
>=20
>      Andrew

Andrew, thanks for all the advice given but I feel like I have to see if th=
e firmware
can be changed to better model the CPU traffic before adding a lot of hacks=
 and
pushing something with the current implementation.

Ioana