> Thanks

Thank you! I love talking about bits and bytes on the network wire and it feels like I get to do it less and less the farther I get into my career... funny how that works. At least I haven't been moved into management yet!

> I'm guessing this is exactly why this stuff is handled at L2 and in the kernel module for the NIC?

Yep, generally the OS driver has a backup version of logic to handle everything beyond "packet receive" and "packet send" for exactly these kinds of reasons. On Linux you or any program with the rights can disable NIC filtering offloads by setting an interface to promiscuous e.g. "ip link set eth1 promisc on" and the packets all get punted to the CPU like it was a base level dumb NIC. Pulling an example early here is a patch making sure the broadcom driver for the NIC in the Raspberry Pi actually listens to this declaration and disables the ARP & ND filtering offloads https://patchwork.kernel.org/project/linux-wireless/patch/15...

> I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?

You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging.

Ideally the device (either NIC offload or upstream OS/further hardware logic) does some MAC learning as the above conversation goes on so things don't always remain unknown flooding past the first exchange but technically just forwarding the frame out all interfaces in the bridge group is valid too (just extremely inefficient). It's also worth noting usually in the real world higher layer discovery (like 2 IP addresses ARPing for each-other) triggers the unicast MAC learning with the ARP broadcast and unicast response but that's just a nicety of how things typically work, it's not always the case with any conversation between 2 Ethernet endpoints. Just knowing the MACs beforehand and not sending any broadcast is technically just as valid a way to do things at the Ethernet layer, albeit extremely rare in the world of IP.

> Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?

More directly things like ARP and WoL offload so the CPU doesn't get interrupts every time some device in the subnet sends an ARP/WoL broadcast, particularly when it ends up being a broadcast intended for a MAC not owned by the local station. Both of those offloads are pretty common in consumer stuff too which is nice and that link I sent above shows a code change related to it for the Raspberry Pi adapter (albeit the Wi-Fi one, which has a whole different world of filters at the Wi-Fi layer before we even get to Ethernet filtering).

TCP offloading and whatnot can be examples as well but the level of abstraction (and varying levels of "what exactly is offloaded") makes it more difficult to discuss than the above examples which can stay within the Ethernet layer (as far as forwarding goes, the payloads may have information beyond that to deal with once delivered). That said I'll leave TCP offload with "the NIC may still need to know the VLAN tag and p-bit to put in the Ethernet header, as well as get the destination MAC of the next hop which could be a gateway or the destination client itself" but skip the examples or further corner cases/combinations since it can get hairy very fast and that already gives enough of an idea about Ethernet bits getting set by the offload too :).