Messages in this thread | | | From | Vladimir Oltean <> | Subject | Re: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on vsc9959 | Date | Thu, 9 Sep 2021 12:01:21 +0000 |
| |
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. | |