Re: [PATCH net-next 00/10] bridge: Allow keeping local FDB entries only on VLAN 0

On 9/9/25 12:07, Nikolay Aleksandrov wrote:
> On 9/9/25 05:27, Jakub Kicinski wrote:
>> On Thu, 4 Sep 2025 19:07:17 +0200 Petr Machata wrote:
>>> Yet another option might be to use in-kernel FDB filtering, and to filter
>>> the local entries when dumping. Unfortunately, this does not help all that
>>> much either, because the linked-list walk still needs to happen. Also, with
>>> the obvious filtering interface built around ndm_flags / ndm_state
>>> filtering, one can't just exclude pure local entries in one query. One
>>> needs to dump all non-local entries first, and then to get permanent
>>> entries in another run filter local & added_by_user. I.e. one needs to pay
>>> the iteration overhead twice, and then integrate the result in userspace.
>>> To get significant savings, one would need a very specific knob like "dump,
>>> but skip/only include local entries". But if we are adding a local-specific
>>> knobs, maybe let's have an option to just not duplicate them in the first
>>> place.
>>
>> Local-specific knob for dump seems like the most direct way to address
>> your concern, if I'm reading the cover letter right. Also, is it normal
>> to special case vlan 0 the way this series does? Wouldn't it be cleaner
>> to store local entries in a separate hash table? Perhaps if they lived
>> in a separate hash table it'd be odd to dump them for VLAN 0 (so the
>> series also conflates the kernel internals and control path/dump output)
>>
>> Given that Nik has authored the previous version a third opinion would> be great... adding a handful of people to CC.
> 
> My 2c, it is ok to special case vlan 0 as it is illegal to use, so it can be used
> to match on "special" entries like this. I'd like to avoid the complexity of maintaining
> multiple hash tables or lists just because of this issue, it is not a common problem
> and I think the optional vlan 0 trick is a nice minimal way to deal with it. We already
> have fdb filtering for dumps, but that requires us to go over all fdbs and with
> fdb duplication the local ones alone can be a pretty high number.
> 

And just to make sure it is clear - usually we are talking about a low number of fdb entries
(w/o duplicates), IIRC up to 100 in most cases.

> The pros are that we don't have fdb duplication (much smaller number of fdbs),
> we use standard bridge infra available to store and find them (the fdb rhashtable,
> with local entries tagged as vlan 0) and code-wise it is pretty simple to maintain.
> This solution has worked for over 10 years at Cumulus, it is well tested.
> 
> It needs to be optional though as it changes user-visible behaviour for local fdbs.
> Any other solution would probably have to be optional as well.
> 
> And obviously I am biased, so good alternatives are welcome too. :-)
> 
> Cheers,
>   Nik
> 
> 
> 
>