Sorry, that went right over my head.
"PR"? How would users know that PR is applied?
Thanks again.
Pull request
It will be closed and merged. You can see the status on the below link.
2 Likes
Thanks d687r02j8g
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.
2 Likes
@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.