Users needed to test 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices

Ok, found it in firewall settings.
Gotta click Software offloading check box to see the Hardware offloading check box. A bit confusing.

Now the magic happened.
This is what I get with arinc9 sysupgrade file hardware offloading enabled on Cudy X6

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec    0             sender
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   930 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  2.04 GBytes   876 Mbits/sec    0             sender
[  7][RX-C]   0.00-20.00  sec  2.04 GBytes   875 Mbits/sec                  receiver

1 Like

Also tested Cudy 2100 with corresponding similar joy.

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec   12             sender
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   930 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  2.04 GBytes   877 Mbits/sec    0             sender
[  7][RX-C]   0.00-20.00  sec  2.04 GBytes   876 Mbits/sec                  receiver

This is the test setup:
test-setup-pic2

1 Like

This is a very good point. Let me start with explaining the bridge offloading feature. This is not related to software or hardware offloading at all.

Quoting from OpenWrt 22.03.0-rc4 fourth release candidate - #91 by arinc9.

There's also this feature called bridge offloading. Most DSA subdrivers implement this. The only one I know that lacks this is the rtl8365mb driver. What this feature does is it offloads traffic between switch ports. Forwarding frames between switch ports will be offloaded to the switch hardware so they don't go through the CPU and exhaust the link to the CPU.

You get full speed on switching between lan0 and lan1 thanks to this.

When lan0 is directly connected to the CPU, you can't benefit this anymore. Hardware offloading will help but it's a layer 3 feature, meaning, packets between the interfaces must be routed.

This is the rule for hardware offloading:

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw

Related patches to the FLOWOFFLOAD target:
openwrt/650-netfilter-add-xt_FLOWOFFLOAD-target.patch at master · openwrt/openwrt
openwrt/800-flowoffload_target.patch at master · openwrt/openwrt

So, it's not a missing configuration but rather a design choice. Switching at CPU level is not very efficient on these SoCs so you'd prefer to do routing instead.

1 Like

@arinc9, what is your reasoning for bringing up the gmac1 as a separate WAN port? Why not patch the dsa driver to fully support multiple cpu ports (there were patches for this before, that for some reason never made it into mainline).

So that we get wan@eth1 and lan1..4@eth0. Or even have it user selectable like: wan@eth1, lan1@eth0, lan2@eth1, lan3@eth0 or what ever combination makes most sense depending the use case.

That would be a DSA-subsystem-wide feature and there's a reason why the said patches never made into mainline. The MT7530 DSA driver already implements this MT7530-switch-specific feature which lets muxing PHY0/4 to GMAC5 of the switch.

Would the D-Link DIR 1960 benefit from this?

Given that the DIR-1960 is included in this patch-set, I would say yes. Basically any MT7621 based device would with a few exceptions as stated in the first post.

@arinc9, I was hoping that OpenWrt could/would accept some multi-cpu dsa patches so more targets would benefit from this even if the mainline kernel will not due to lack of consensus how to implement it. @Ansuel tried and failed on mainline with this if I remember correctly, even it worked perfectly on the his targets.

I agree, however, this is not really my concern.

is there an upgrade package for the DIR-1960? I have not done the patch route before but im comfortable doing it as long as i know the process.

EDIT---- Nevermind i located it