2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices

I've not tried this but seems promising

Nice job.
I see on your list of devices, you included Zyxel NR7101, which is a 5G Router.
It uses Wwan/Lan connection, but on iperf, if i test lan speed, i cannot reach full speed as well.
Does this patch can affect the mobile connection as well, increasing the lan speed from zyxel to another Router?
Or, can it be done to also increase WWAN/LAN speed?

Sorry for late reply, it’s been a busy day. No, it won’t affect wireless connection speed.

Do you happen to know whether it would be possible at all on an mt7621_ubnt_edgerouter-x-sfp with SFP being on external phy (eth5)?

I may have read something that bandwidth got split in max 1Gpbs because of internal wiring, but am not sure.

I tested EdgeRouter X SFP back in time. Here's what I recorded after my tests.

Ubiquiti EdgeRouter X SFP: External phy is wired TX→TX to the rgmii2 pinouts which needs the rgmii2 pin group claimed with gpio function to work. Muxing an internal phy to gmac1 results in only being able to receive traffic when the rgmii2 pin group is claimed with rgmii2 function.

I've tested this on an mt7621 device that is not officially supported yet: Adding OpenWrt support for Arcadyan WE420223-99 (KPN Experia WiFi) - #11 by Harm . It has only two Ethernet ports. I found that when the ports are used as a switch, this patch negatively affects performance. The CPU gets to handle all the traffic. Though when I use it as a router (so NAT) between the ports, the hardware offloading kicks in and forwards traffic at near-wirespeed.

So before having lan0 and lan1 in br-lan made it a switch where the cpu does not have to process the traffic, after the patch this makes the CPU do the work of forwarding packets. Am I missing a config setting?

a small question:
can this be of interest because I only use the MT7621 routers as relays or WIFI access points with the lan ports connected directly to the WAN port?

The modem in the NR7101 is wired to the SoC internal xhci controller so it won't be directly affected by this. In theory it could take some advantage of the extra bandwidth between cpu and switch, but it's hard to see where you'd use that bandwidth given the single ethernet port...

Answered here Users needed to test 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices - #53 by arinc9

Tried it on Cudy-X6

Tested straight through cable connecting to hosts. Get close to 1Gbps in both directions.
Test with router inline. Similar to arinc9 test except iperf3 client and server are separate hosts.
With 22.03 rc5 see about 1Gbps total.

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-5.00   sec  83.8 MBytes   141 Mbits/sec   46             sender
[  5][TX-C]   0.00-5.00   sec  82.5 MBytes   138 Mbits/sec                  receiver
[  7][RX-C]   0.00-5.00   sec   441 MBytes   740 Mbits/sec  219             sender
[  7][RX-C]   0.00-5.00   sec   438 MBytes   734 Mbits/sec                  receiver

With arinc9 sysupgrade see about the same

 - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec   443 MBytes   186 Mbits/sec  280             sender
[  5][TX-C]   0.00-20.01  sec   439 MBytes   184 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  1.48 GBytes   637 Mbits/sec   28             sender
[  7][RX-C]   0.00-20.01  sec  1.48 GBytes   635 Mbits/sec                  receiver

I uploaded sysupgrade and did not keep config.
All I did was change IP addresses on router.
Is there some other config required?
hardware offload? where is that?

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:

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.


@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

I can confirm that on the DLINK DIR-1960 (and therefore 2660 also) all seems to work just fine. I have not done a full duplex speed test but the image itself and wan port are both working.