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

On Thu, Sep 09, 2021 at 01:33:57PM +0200, Joergen Andreasen wrote:

quoted

quoted

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/ (local)

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.