add etherbridge, the guts of a learning bridge that can be reused.
authordlg <dlg@openbsd.org>
Sun, 21 Feb 2021 03:26:46 +0000 (03:26 +0000)
committerdlg <dlg@openbsd.org>
Sun, 21 Feb 2021 03:26:46 +0000 (03:26 +0000)
commit5a88a7345428e9da5a05349249d21b1afb03f65c
tree4e5f93c6e3e27166de7c0a901dfa99a9ec8190d4
parent4d1f2a5337ce0d5967ad6f6d5a586f9233eba121
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@
sys/conf/files
sys/net/if_etherbridge.c [new file with mode: 0644]
sys/net/if_etherbridge.h [new file with mode: 0644]