On 16/05/2023 14:10, Vladimir Oltean wrote: > On Tue, May 16, 2023 at 02:04:30PM +0300, Nikolay Aleksandrov wrote: >> That was one of the questions actually. More that I'm thinking about this, the more >> I want to break it apart by type because we discussed being able to specify a flag >> mask for the limit (all, dynamic, dynamic+static etc). If we embed these stats into a >> bridge fdb count attribute, it can be easily extended later if anything new comes along. >> If switchdev doesn't support some of these global limit configs, we can pass the option >> and it can deny setting it later. I think this should be more than enough as a first step. > > Ok, and by "type" you actually mean the impossibly hard to understand > neighbor discovery states used by the bridge UAPI? Like having Yes, that is what I mean. It's not that hard, we can limit it to a few combinations that are well understood and defined. > (overlapping) limits per NUD_REACHABLE, NUD_NOARP etc flags set in > ndm->ndm_state? Or how should the UAPI look like? Hmm, perhaps for the time being and for keeping it simpler it'd be best if the type initially is just about dynamic entries and the count reflects only those. We can add an abstraction later if we want "per-type"/mask limits. Adding such abstraction should be pretty-straight forward if we keep in mind the flags that can change only under lock, otherwise proper counting would have to be revisited.
