net: dsa: flush the dynamic FDB of the software bridge when fast ageing a port
authorVladimir Oltean <vladimir.oltean@nxp.com>
Sun, 8 Aug 2021 14:35:25 +0000 (17:35 +0300)
committerDavid S. Miller <davem@davemloft.net>
Sun, 8 Aug 2021 19:56:51 +0000 (20:56 +0100)
commit9264e4ad26112a496398159d200af017e37d97e3
treebf23a4da82634b432f1cfd189c05b28089838f51
parent4eab90d9737b348094a99ba4e4c473e91a8b8038
net: dsa: flush the dynamic FDB of the software bridge when fast ageing a port

Currently, when DSA performs fast ageing on a port, 'bridge fdb' shows
us that the 'self' entries (corresponding to the hardware bridge, as
printed by dsa_slave_fdb_dump) are deleted, but the 'master' entries
(corresponding to the software bridge) aren't.

Indeed, searching through the bridge driver, neither the
brport_attr_learning handler nor the IFLA_BRPORT_LEARNING handler call
br_fdb_delete_by_port. However, br_stp_disable_port does, which is one
of the paths which DSA uses to trigger a fast ageing process anyway.

There is, however, one other very promising caller of
br_fdb_delete_by_port, and that is the bridge driver's handler of the
SWITCHDEV_FDB_FLUSH_TO_BRIDGE atomic notifier. Currently the s390/qeth
HiperSockets card driver is the only user of this.

I can't say I understand that driver's architecture or interaction with
the bridge, but it appears to not be a switchdev driver in the traditional
sense of the word. Nonetheless, the mechanism it provides is a useful
way for DSA to express the fact that it performs fast ageing too, in a
way that does not change the existing behavior for other drivers.

Cc: Alexandra Winter <wintera@linux.ibm.com>
Cc: Julian Wiedmann <jwi@linux.ibm.com>
Cc: Roopa Prabhu <roopa@nvidia.com>
Cc: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/dsa/port.c