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:

quoted

On Thu, 4 Sep 2025 19:07:17 +0200 Petr Machata wrote:

quoted

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