On 16/05/2023 13:44, Vladimir Oltean wrote: > On Tue, May 16, 2023 at 01:32:05PM +0300, Nikolay Aleksandrov wrote: >> Let's take a step back, I wasn't suggesting we start with a full-fledged switchdev >> implementation. :) I meant only to see if the minimum global limit implementation >> suggested would suffice and would be able to later extend so switchdev can use and >> potentially modify (e.g. drivers setting limits etc). We can start with a simple >> support for limits and then extend accordingly. The important part here is to >> not add any uAPI that can't be changed later which would impact future changes. > > I guess adding a global per-bridge learning limit now makes sense and > would not unreasonably hinder switchdev later on. The focus is on > "learning limit" and not a limit to user-created entries as Johannes has > currently done in v1. I don't necessarily see an urgent need for > IFLA_BR_FDB_CUR_ENTRIES, given the fact that user space can dump the FDB > and count what it needs, filtering for FDB types accordingly. Having the current count is just a helper, if you have a high limit dumping the table and counting might take awhile. Thanks for the feedback, then we'll polish and move on with the set for a global limit.
