etherbridge_map was way too clever, so simplify it.

the code tried to carry state from the quick smr based lookup through
to the actual map update under the mutex, but this led to refcnt
leaks, and

etherbridge_map was way too clever, so simplify it.

the code tried to carry state from the quick smr based lookup through
to the actual map update under the mutex, but this led to refcnt
leaks, and logic errors. the simplification is that if the smr based
checks say the map needs updating, we prepare the update and then
forget what we learnt inside the smr critical section and redo them
under the mutex again.

entries in an etherbridge map are either in it or they aren't, so
we don't need to refcnt them. this means the thing that takes an
entry out of the map becomes directly responsible for destroy it,
so they can do the smr call or barrier directly rather than via a
refcnt.

found by hrvoje popovski while testing the stack running in parallel,
and fix tested by him too.
ok sashan@

show more ...

spelling

ok gnezdo@ semarie@ mpi@

only store the current time on address table entries if it changes.

this avoids unecessary writes to memory. it helps a little bit with
a single nettq, but we get a lot more of a boost in pps when r

only store the current time on address table entries if it changes.

this avoids unecessary writes to memory. it helps a little bit with
a single nettq, but we get a lot more of a boost in pps when running
concurrently.

thanks to hrvoje for testing.

show more ...

use a uint64_t for the ethernet address in the etherbridge table.

testing has shown up to a 30% improvement in the veb forwarding
rate with this change.

an earlier diff was tested by hrvoje popovsk

use a uint64_t for the ethernet address in the etherbridge table.

testing has shown up to a 30% improvement in the veb forwarding
rate with this change.

an earlier diff was tested by hrvoje popovski
tested on amd64 and sparc64

show more ...

whitespace tweaks, no functional change.

add support for adding and deleting address table entries.

add etherbridge, the guts of a learning bridge that can be reused.

this allows for the factoring out of the learning bridge code i
wrote in bpe and nvme, and should be reusable for other drivers
nee

add etherbridge, the guts of a learning bridge that can be reused.

this allows for the factoring out of the learning bridge code i
wrote in bpe and nvme, and should be reusable for other drivers
needing a mac learning bridge.

the core data structures are an etherbridge struct to represent the
learning bridge, eb_entry structs for each mac address entry that
the bridge knows about, and an etherbridge_ops struct that drivers
fill in so that they can use this code.

eb_entry structs are stored in a hash table made up of SMR_TAILQs
to support lookups of entries quickly and concurrently in the
forwarding path. they are also stored in a locked red-black tree
to help manage the uniqueness of the mac address in the table.

the etherbridge_ops handlers mostly deal with comparing and testing
the "ports" associated with mac address table entries. the "port"
that a mac address entry is associated with is opaque to the
etherbridge code, which allows for this code to be used by nvgre
and bpe which map mac addresses inside the bridge to addresses in
their underlay networks. it also supports traditional bridges where
"ports" are actual interfaces.

ok patrick@ jmatthew@

show more ...