Messages in this thread | | | Date | Mon, 29 Jul 2019 18:35:06 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH 0/5] staging: fsl-dpaa2/ethsw: add the .ndo_fdb_dump callback |
| |
On Mon, Jul 29, 2019 at 07:11:47PM +0300, Ioana Ciornei wrote: > This patch set adds some features and small fixes in the > FDB table manipulation area. > > First of all, we implement the .ndo_fdb_dump netdev callback so that all > offloaded FDB entries, either static or learnt, are available to the user. > This is necessary because the DPAA2 switch does not emit interrupts when a > new FDB is learnt or deleted, thus we are not able to keep the software > bridge state and the HW in sync by calling the switchdev notifiers. > > The patch set also adds the .ndo_fdb_[add|del] callbacks in order to > facilitate adding FDB entries not associated with any master device. > > One interesting thing that I observed is that when adding an FDB entry > associated with a bridge (ie using the 'master' keywork appended to the > bridge command) and then dumping the FDB entries, there will be duplicates > of the same entry: one listed by the bridge device and one by the > driver's .ndo_fdb_dump). > It raises the question whether this is the expected behavior or not.
DSA devices are the same, they don't provide an interrupt when a new entry is added by the hardware. So we can have two entries, or just the SW bridge entry, or just the HW entry, depending on ageing.
> Another concern is regarding the correct/desired machanism for drivers to > signal errors back to switchdev on adding or deleting an FDB entry. > In the switchdev documentation, there is a TODO in the place of this topic.
It used to be a two state prepare/commit transaction, but that was changed a while back.
Maybe the DSA core code can give you ideas?
Andrew
| |