Jakub Kicinski <kuba@xxxxxxxxxx> writes: > 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) I'm not sure why it would be helpful to keep them separate. You would still need to dump them presumably? Or maybe there's a way to request skipping specifically local entries, but then you don't need to keep them separate? I find it better to not create them in the first place, because then you have faster iteration in all for-each-fdb contexts, faster marshalling, less memory taken. > Given that Nik has authored the previous version a third opinion would > be great... adding a handful of people to CC.
