>> The Original Issue:

I was assuming many devices on newer RouterOS versions, specifically HeX and 4011 in my case, would keep HW offload on with RSTP enabled, per the chart on the new wiki (below), but found out the hard way that they do not and will turn off HW offload through at least v6.49.6 ST (it seems v7+ or maybe v7.1+ fixes it per my note below, but in testing I went 6.48.6->6.49.6->7.2.3 so can't say specifically).



>> Details, Wiki Incongruity and Wiki Fix:

The footnote on the new wiki does say that v7.1 release candidates added *bridge VLAN filtering* for these two switch chips, but says nothing about when *RSTP hardware offload* was added. As such, is implied that it has worked fine since 6.41 in the paragraph above the chart (which was copied from the old wiki) since there are no [foot]notes to specify it was only supported past a certain point. My guess is RSTP on those switch chips was added at the same time as the VLAN-filtering and the footnote can just be updated, plus tagged on those entries in the chart, but I don't know for sure and this will probably have to be checked by someone internal to Mikrotik unless I'm missing something in the changelogs.

On this, I've tried looking through the changelogs, expanding all and searching for "7621", "8367", "RSTP", "offload", and "Hex" but only see the VLAN-filtering support per the note above, but nothing about RSTP or other bridging- and HW-offload-related features. Maybe it was not in the patch notes and that's why the wiki is not correct/out of date?

New Wiki -- Bridge Offloading: https://help.mikrotik.com/docs/display/ ... Offloading
Old Wiki -- Bridge Offloading: https://wiki.mikrotik.com/wiki/Manual:I ... Offloading



>> Diagnosis of underlying cause and plausible/suggested process fix:

Since this took me a while to figure out what was wrong and I found out only after clients complained about what I later realized were switching speed issues, I'd suggest it would be worth figuring out how this happened so others don't make the same mistake and so it hopefully can be avoided in the future. My guess is the patch notes weren't updated fully per what I said above and that the wiki maintainers ostensibly rely on the patch notes, at least as a guide, to keep the wiki up to date, so that's probably the extent of the issue.

My guess is RSTP on those switch chips was added at the same time as the VLAN-filtering and the footnote can just be updated

Yes, for devices using RTL8367 (like RB4011), l2hw offload for STP/RSTP was introduced at the same time as VLAN filtering.
And because ether1-5 and ether 6-10 are connected to different switch chips, l2hw offload only works inside the groups ether1-5 and ether6-10.

Just in case: Enabling IGMP or DHCP snooping on a RTL8367 based bridge still disables l2hw offload.

My guess is RSTP on those switch chips was added at the same time as the VLAN-filtering and the footnote can just be updated

Yes, for devices using RTL8367 (like RB4011), l2hw offload for STP/RSTP was introduced at the same time as VLAN filtering.
And because ether1-5 and ether 6-10 are connected to different switch chips, l2hw offload only works inside the groups ether1-5 and ether6-10.

Just in case: Enabling IGMP or DHCP snooping on a RTL8367 based bridge still disables l2hw offload.

Thanks. Marking as accepted answer though HeX/MT7621 isn't technically confirmed there, but for now I'll take it on faith that the HeX was fixed the same way at the same time.


To Mikrotik: Please verify this info and extend footnote #3 on the new wiki (link above in OP) to include "added STP/RSTP and MSTP" plus tag MT7621 and RTL8367 with that footnote.