You can call them “functionality” if you wish. But, as already mentioned, term “bridge” is overloaded with (actually) 3 distinct features with only vague connection (but they are strongly connected). There’s no need to go into details about those 3 features, @sindy did it splendidly in this forum topic. Since they are distinct, but not unconnected, I like to call them “personalities” (just like dr. Jekyll and Mr. Hyde … but in this case, all personalities are active at all times, it only depends from which perspective one looks at bridge).
Yes, there’s only one type of bridge. But it’s flexible in what functions it does do (or at all), depending on how it’s set up. According to different personalities 
:
- the CPU-facing bridge port. It’s created automatically with the creation of bridge and is permanently attached as bridge port. But it can be “disconnected” in a sense that it’s not referenced by any other configuration at all (e.g. it doesn’t have IP address bound, it doesn’t have VLAN interface attached, etc.). Just the same as with e.g. “dummy” switch with multiple ethernet RJ45 ports, but one is physically blocked and no ethernet device is ever connected to that RJ45 port. The port exists, but it’s never used. However it will never show as “not connected” (unlike physical RJ45 ports) due to existence of switch-facing interface discussed in bullet #3 below.
- the switch-like personality: it’s always there, without it one could not add multiple interfaces as bridge ports (in essence: that’s the reason for existence of /interface/bridge/port sub-tree). And it’s in use as soon as one adds first interface as bridge port … because that would be the second port of the bridge (the first being above mentioned CPU-facing bridge port) and this personality does forwarding of ethernet frames between different bridge ports according to it’s own forwarding rules.
This personality can execute different functions if they are enabled and configured, e.g.:
- handling of VLAN tags (tagging, untagging, filtering, etc.) if bridge has vlan-filtering enabled
- running bridge filters if configured
- running IP firewall rules against passing frames if configured
- etc.
Since bridge functions largely overlap with functions of a typical switch chip, those functions can be offloaded to switch chip if it exists and functions enabled and configured are supported by the particular switch chip type.
It may be worth noticing that when a bridge only has one member port, otherwise connected to hardware switch chip, there’s nothing to be offloaded to actual hardware. Hardware only acts on frames passing between ports directly attached to it. But it doesn’t accept frames from (software) bridge, perform some function and return resulting frame back to (software) bridge. Example of such working would be traffic between e.g. wifi interface and eoip interface where bridge has to manipulate VLAN headers. It will always be the software performing these functions for traffic between said interfaces, frames won’t be passed to switch chip. OTOH the same bridge won’t even touch frames which will pass e.g. ether1 and ether2 (if ether1 and ether2 are ports of the same bridge as beforementioned wifi1 and eoip interfaces) if bridge functions are offloaded to switch chip. And all of this means that it’s pointless to force HW offload of bridge which has only one member port attached to switch chip.
- switch-facing interface which is also created automatically with the creation of bridge and is permanently mapped to bridge CPU-facing port. Here one has to define what is interface (in contrast with port). In this sense interface is entity which allows L3 stack (e.g. IPv4, IPv6, etc.) to set it’s own attributes (e.g. IP address) and communicate with certain L2 domain (e.g. physical ethernet infastructure, or VLAN). And port is an L2 connection point (which talks to L1 … e.g. ethernet port adds ethernet envelope to L3 packet and passes it down to MII which can work with electrical signals over UTP). Again one can decide not to use it by not attaching any L3 configuration to it.
A side note: MAC address settings on bridge apply to this personality because bridge only needs MAC when router (the L3 entity) communicates with devices, connected to the same L2 domain. A switch doesn’t “leave traces” in switched frames, hence it doesn’t need own MAC address.
And, as mentioned, each of these 3 personalities are configured individually. Clearly personality #2 (switch-like entity) is unique (software) personality inside a routerboard device (no other entities can do switching between member ports. Other two personalities are each member of larger family of similar entities:
- CPU-facing port is similar to ethernet ports, WiFi interfaces, L2 tunneling interfaces (such as EOIP) … which can all be used as bridge ports … or directly as L3 interfaces
- switch-facing interface is mostly L2 port, as seen “from the other side” (all L2 ports can also serve as interfaces, used by ROS). But there are interfaces which can’t be used as ports (or as L2 entities if you want), e.g. all L3 tunneling interfaces, such as IPIP, wireguard, etc. If one want so use such interface, L3 setup is required (e.g. IP address set and referenced in routing configuration).
Example of using bridge as solely L2 entity (so avoiding personalities #1 and #3) but in a non-trivial way, would be:
/interface/bridge
add bridge=BRexample vlan-filtering=yes ingress-filtering=yes frame-types=admit-only-vlan-tagged
# the later property in bridge definition is in this example only set to invalidate the implicit PVID setting
/interface/bridge/port
add bridge=BRexample interface=ether1 pvid=666 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes
add bridge=BRexample interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged ingress-filtering=yes
add bridge=BRexample interface=wifi1 pvid=333 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes
/interface/bridge/vlan
add bridge=BRexample tagged=sfp-sfpplus1 untagged=wifi1 vlan-ids=333
add bridge=BRexample tagged=sfp-sfpplus1 untagged=ether1 vlan-ids=666
(definition of untagged ports in /interface/bridge/vlan is not necessary in recent ROS versions, but they are there to make example clear)
So bridge CPU-facing port is set as tagged-only but it’s not set as member of any VLANs. Enabling ingress-filtering is important to ensure that bridge switch-facing interface can not inject frames with VID set to “foreign” VLAN IDs … and in this case, all VLAN IDs are “foreign” as bridge is not member of any VLANs. And due to setting frame-types=admit-only-vlan-tagged that’s also true for (implicitly set) PVID=1. If it was not for this setting, bridge would be (untagged) member of VLAN1 which would make possible to inject frames to VLAN 1.
So bridge switch-facing interface is effectively disabled as no traffic between bridge CPU-facing port and the rest of switch-like entity is allowed. Which leaves only personality #2 (switch-like entity) alive and kicking.