Contributed by Paul 'WEiRD' de Weerd on from the very-efficient-bridge(4) dept.
add veb(4), a Virtual Ethernet Bridge driver. my intention is to replace bridge(4), but the way it works is different enough from from bridge that a name change is justified to distinguish them. it also makes it easier to commit it to the tree and work on it in parallel to bridge, and allows a window of migration. the main difference between veb(4) and bridge(4) is how they use interfaces as ports. veb takes over interfaces completely and only uses them to receive and transmit ethernet packets. bridge also use each interface as a port to the ethernet segment it's connected to, but also tries to continue supporting the use of the interface as a way to talk to the network stack on the local system. supporting the use of interfaces for both external and local communication is where most of my confusion with bridge comes from, both when i'm trying to operate it and also understand the code. changing this semantic is where most of the simplification in veb comes from compared to bridge. because veb takes over interfaces, the ethernet network set up on a veb is isolated from the host network stack. by default veb does not interact with pf or the ip (and mpls) stacks. to enable pf for ip frames going over veb ports link1 on the veb interface must be set. to have the stack interact with a veb network, vport interfaces must be created and added as ports to a veb. the vport interface driver is provided as part of veb, and is handled specially by veb. veb usually prevents the use of ports by the stack for sending an receiving packets, but that's why vports exist, so veb has special handling for them. veb already supports a lot of the other features that bridge has, including bridge rules and protected domains, but i got tired of working out of the tree and stopped implementing them. the main outstanding features is better address table management, the blocknonip flag on ports, transparent ipsec interception, and spanning tree. i may not bother with spanning tree unless someone tells me that they actually use it. the core ethernet learning bridge functionality is provided by the etherbridge code that was factored out of nvgre and bpe. veb is already (a lot) faster than bridge, and is better prepared to operate in parallel on multiple CPUs concurrently. thanks to hrvoje popovski for testing some earlier versions of this. discussed with many ok patrick@ jmatthew@
While performance wasn't the main goal for the veb(4) bridge code, it does run a bit faster, as David explained in an e-mail to tech@:
oh, veb(4) should be a lot faster than bridge(4) too. and mpsafe. and able to be run concurrently. hrvoje popovski has tested some versions of these diffs and has the following numbers so far: > 3550m4 - slower box > forwarding - 560 Kpps > bridge - 400 Kpps > veb - 850 Kpps > tpmr - 920 Kpps > > r620 - faster box > forwarding - 1 Mpps > bridge - 680 Kpps > veb - 1.5 Mpps > tpmr - 1.75 Mpps
If you're currently using bridge(4), you may want to give the new veb(4) a try! Getting some more real-world experience with the new code will help flush out the bugs, if any.
(Comments are closed)