Re: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on vsc9959

[Vladimir Oltean]

On Thu, Sep 09, 2021 at 01:33:57PM +0200, Joergen Andreasen wrote:
> > > Yes, Using redirect action can give PSFP filter a forward port to
> > > add
> > > MAC table entry. But it also has the issue that when using "bridge
> > > fdb
> > > del" to delete the MAC entry will cause the tc-filter rule not
> > > working.
> >
> > We need to define the expected behavior.
> >
> > As far as the 802.1Q-2018 spec is concerned, there is no logical
> > dependency between the FDB lookup and the PSFP streams. But there
> > seems
> > to be no explicit text that forbids it either, though.
> >
> > If you install a tc-redirect rule and offload it as a bridge FDB
> > entry,
> > it needs to behave like a tc-redirect rule and not a bridge FDB
> > entry.
> > So it only needs to match on the intended source port. I don't
> > believe
> > that is possible. If it is, let's do that.
> >
> > To me, putting PSFP inside the bridge driver is completely outside of
> > the question. There is no evidence that it belongs there, and there
> > are
> > switch implementations from other vendors where the FDB lookup
> > process
> > is completely independent from the Qci stream identification process.
> > Anyway, this strategy of combining the two could only work for the
> > NULL
> > stream identifiers in the first place (MAC DA + VLAN ID), not for the
> > others (IP Stream identification etc etc).
> >
> > So what remains, if nothing else is possible, is to require the user
> > to
> > manage the bridge FDB entries, and make sure that the kernel side is
> > sane, and does not remain with broken data structures. That is going
> > to
> > be a PITA both for the user and for the kernel side, because we are
> > going to make the tc-flower filters effectively depend upon the
> > bridge
> > state.
> >
> > Let's wait for some feedback from Microchip engineers, how they
> > envisioned this to be integrated with operating systems.
>
> We at Microchip agrees that it is a difficult task to map the PSFP
> implementation in Felix to the “tc flower” filter command, but please
> remember that Ocelot and its derivatives were designed long before
> the 802.1Qci standard was ratified and also before anyone has
> considered how to control it in Linux.
>
> We think that the best approach is to require the user to manage
> bridge FDB entries manually as suggested by Xiaoliang.
>
> Our newer PSFP designs uses the TCAM instead of the MAC table
> which maps a lot better to the “tc flower” filter command.

Well, that's even more unfortunate, because as explained by Ido here:
https://lore.kernel.org/netdev/YSHzLKpixhCrrgJ0@shredder/

the return code from SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE event handlers is
not propagated to br_switchdev_fdb_notify. So in effect, the device driver
cannot stop the bridge from removing an FDB entry which would lead it to
having a broken tc filter.

Now, the ocelot switchdev driver uses the bridge bypass .ndo_fdb_add and
.ndo_fdb_del, while DSA actually listens for switchdev events on the
atomic call chain. So any solution needs to work with switchdev, not
just with the bridge bypass ops.