On Thu, Mar 30, 2023 at 04:54:19PM +0200, Hans Schultz wrote:
I don't know if you have a solution in mind wrt the behaviour of the offloaded flag if it is not to do as it does now and let the bridge age out dynamic entries. That led me to conclude that this patch-set cannot use the offloaded flag, but you seem to suggest otherwise.
If you have a suggestion, feel free.
Didn't I explain what I would do from the first reply on this thread? https://patchwork.kernel.org/project/netdevbpf/patch/20230318141010.513424-3...
As a bug fix, stop reporting to switchdev those FDB entries with BR_FDB_ADDED_BY_USER && !BR_FDB_STATIC. Then, after "net" is merged into "net-next" next Thursday (the ship has sailed for today), add "bool static" to the switchdev notifier info, and make all switchdev drivers (everywhere where a SWITCHDEV_FDB_ADD_TO_DEVICE handler appears) ignore the "added_by_user && !is_static" combination, but by their own choice and not by switchdev's choice.
Then, make DSA decide whether to handle the "added_by_user && !is_static" combination or not, based on the presence of the DSA_FDB_FLAG_DYNAMIC flag, which will be set in ds->supported_fdb_flags only for the mv88e6xxx driver. When DSA_FDB_FLAG_DYNAMIC is not supported, DSA will not offload the FDB entry: neither will it call port_fdb_add(), nor will it emit SWITCHDEV_FDB_OFFLOADED. Ideally, it would also inform user space that it can't offload this flag by returning an error, but the lack of an error propagation mechanism from switchdev to the bridge FDB is a known limitation which is hard to overcome, and is outside the scope of your patchset I believe. To see whether DSA has acted upon the "master dynamic" flag or not, it would be good enough for the user to see something adequate in "bridge fdb show | grep offloaded", I believe.