Introducing veb(4) - a new Virtual Ethernet Bridge

In this commit, David Gwynne (dlg@) adds a new veb(4) driver to the tree. David's goal is to replace the old bridge(4) driver:

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.