Matthew Grooms: > > over the last few days i have been doing a bit of work on VLAN filtering > > for bridge(4), which i thought i'd mention here in case anyone is > > interested. the purpose of this is to extend the existing bridge VLAN > > support to make it more generally useful. > > Looks awesome. Thanks for working on this. Any idea what the overhead is wrt > packet forwarding rate? Any performance numbers comparing your bridge access > port feature vs vlan + bridge?
i haven't done any benchmarking yet, but i don't expect any significant performance improvement; if anything it's probably the same or slightly worse, although if you're bridging a lot of VLANs, there may be some performance benefit from having 1 bridge instead of hundreds of bridges and thousands of vlan(4) interfaces. the patches do introduce a new bridge_lookup_member_if() call (which is a linked list walk of bridge members) in bridge_enqueue(), but this is only if the caller didn't already have the member pointer, which is (iirc) for dummynet traffic and some locally-originated traffic. bridge_input() already did this list walk for forwarded traffic (i.e., that was already there before my changes). i would like to avoid these calls entirely (including the existing call in bridge_input() for every packet) by replacing the if_bridge pointer in struct ifnet with a pointer to the bridge_iflist, then adding a backpointer from bridge_iflist to the bridge softc; this should mean we never need to do a list walk to forward traffic, but i need to understand the lifetime issues here first (e.g., what happens if a bridge member is removed while a packet is in a queue somewhere and will be delivered later). bridge_input() also does a second list walk in GRAB_OUR_PACKETS to find traffic destined for the local host, which we could avoid with a sysctl to ignore Ethernet traffic for MAC addresses other than the bridge itself. this would break configurations where IP addresses are assigned to bridge member interfaces, but that's always been the wrong way to configure it, so it's not a huge loss. for the VLAN filtering itself, the VLAN allow list is stored as an array of 4096 bits (64x uint64_t) which only needs a bit test for each packet, so i don't expect that to have any noticable impact on forwarding performance. if there is a performance loss, it will be from the need to fetch the bridge_iflist where we didn't need to before. but, i want to make sure the feature itself works before introducing any new bugs trying to optimise it :-) i do think there are some worthwhile performance gains to had even in the existing bridge code, though. i will at some point do a benchmark of the new code with none of the new features enabled just to make sure we don't have too much performance regression for existing setups.
