On 21/09/2026 16:44, Ido Schimmel wrote:
On Fri, Sep 18, 2026 at 06:29:41PM +0300, Nikolay Aleksandrov wrote:
Hi,
This patch-set is the first step to removing unnecessary VLAN hash lookups
from the bridge fast-path and also provides additional broadcast path
optimization by considering only the port-VLANs that actually participate
in the VLAN instead of all bridge ports. Combined these changes bring
considerable improvements[1] and open the path to do the same for the most
common fdb forwarding path. As expected the pathological cases have the
largest gain, e.g. if we have 1 client / VM facing port and 1 upstream port
only participating in a VLAN with many other bridge ports, we consider only
those 2 when broadcasting in that VLAN.
For up to 8 ports we only use the port-VLAN list as the array doesn't make
much of a difference and is unnecessary. Note that the array is rebuilt on
every member add or delete when >8 members, I tested that and could do
2000 VLAN add/delete with 64 port-VLAN members / sec on my test VM.
If it ever becomes a problem we can optimize it further, for the time
being I prefer it is simpler.
Very nice!
Reviewed-by: Ido Schimmel <[email protected]>
Thank you!
A couple of nits that you can handle later (or not):
1. Patch #3:
__vlan_delete_pvid(vg, rtnl_dereference(vg->pvid));
Can be simplified to:
RCU_INIT_POINTER(vg->pvid, NULL);
2. Patch #7:
Initially I thought that 'fwd.vlan' is never set, but then I realized
that in the only place where this field is actually set it's called
'dst.vlan', which is a bit confusing given that in the context of the
bridge driver 'dst' is usually an FDB entry. I would probably rename it
to 'fwd' to be consistent with the rest of the code.
Ack, I will deal with these in a follow-up, I have another set that removes
the two egress vlan hash lookups for standard unicast fdb path and will add
these as cleanups to it.
Cheers,
Nik
