summaryrefslogtreecommitdiff
path: root/sys/dev/acpi/ccp_acpi.c
diff options
context:
space:
mode:
authorDavid Gwynne <dlg@cvs.openbsd.org>2021-02-21 03:26:47 +0000
committerDavid Gwynne <dlg@cvs.openbsd.org>2021-02-21 03:26:47 +0000
commit4e4289f37dd214192ac52f0bb2879d85004acd3c (patch)
tree07e660862512756203a563574baa0ac11ddbb43d /sys/dev/acpi/ccp_acpi.c
parent7dc321c69f8afbaa2e0e6e44abaf99075a9dc37c (diff)
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@
Diffstat (limited to 'sys/dev/acpi/ccp_acpi.c')
0 files changed, 0 insertions, 0 deletions