That's right.
Hi @arinc9. I have a ER-X-SFP and I am interested in helping with hardware offloading support on this device (though I am not really comfortable with low-level network concepts). How one could help you?
Hi.
This morning, mt7621 switched to kernel 5.15 on master. I have tested HW offloading and performances are very good, almost 1Gb/s.
EDIT : device Netgear R6220.
First, you need to understand that hardware offloading would only help if there's another switch port directly connected to the CPU. The wiring on the SFP port of ER-X-SFP is in a way that it's not directly connected to the CPU. So the remaining option is to use phy 0 or 4 which can connect directly to the CPU. This is what I originally asked to be tested. If this makes sense to you, I can send you a build to test it.
So phy 0 and 4 can connect directly to the CPU, the SFP port is not, and what about phy 1, 2 and 3?
Testing would be to transfer data between phy 0 and 4 and measure the speed? If so, I can do that 
phy 1, 2, and 3 cannot. You don't need to test transfering data between phy0 and phy4. Just see whether you can access the router itself via the eth0 port. Here are the images.
https://files.arinc9.com/OpenWrt/
I've got some more tests regarding the SFP port after this.
I built yesterday's master snapshot (kernel 5.15) and I get 860mbps bidirectional in lan.
should I get the same in Wan? I cannot test as I have not 1gbps but 300mpbs wan
Thank you
A LAN <-> LAN doesn't involve the routing feature, so you may have a full Gbits/s.
To simulate a Gbit/s WAN, just plug a computer on the WAN. You need to manually set IP on both the PC and the WAN. Use iperf3 much testing.
what if I create two networks? lets say 192.168.1.0/24 (lan port) and 192.168.2.0/24 (wan port) . test between them would test routing troughoutput ?
1 Like
Yeah that will work.
Just to confirm - where a device is listed as ācannot benefitā I assume that this is something that cannot be worked around without a hardware mod? I have an Archer C6 v3 and I get that the WPS button is using a GPIO pin which clashes with RGMII2.
I wouldnāt mind installing a firmware with faster routing and no WPS button, but I donāt want to end up with custom hardware Iāve soldered myself!
I don't know why C6 v3 was left out, C6U which is hardware identical was converted.
C6 v3 is only lacking the USB port.
The WPS button for the C6U is on GPIO 10 but for the C6/A6 itās on GPIO 28 which clashes with RGMII2
Yeah, you can disable the button in the devicetree in favor of using gmac1. I can send you a test build if you'd like.
If you can build yourself, you can apply this diff.
diff --git a/target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi b/target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi
index 217c1b60fe..2b2f6cfbf4 100644
--- a/target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi
+++ b/target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi
@@ -21,13 +21,6 @@
keys {
compatible = "gpio-keys";
- wps {
- label = "wps";
- gpios = <&gpio 28 GPIO_ACTIVE_LOW>;
- debounce-interval = <60>;
- linux,code = <KEY_WPS_BUTTON>;
- };
-
reset {
label = "reset";
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
@@ -115,7 +108,7 @@
&state_default {
gpio {
- groups = "i2c", "rgmii2", "uart2", "uart3", "jtag", "wdt";
+ groups = "i2c", "uart2", "uart3", "jtag", "wdt";
function = "gpio";
};
};
@@ -148,22 +141,29 @@
};
};
-ðernet {
- pinctrl-0 = <&mdio_pins>, <&rgmii1_pins>;
+&gmac0 {
+ nvmem-cells = <&macaddr_config_8>;
+ nvmem-cell-names = "mac-address";
};
-&gmac0 {
+&gmac1 {
+ status = "okay";
+ label = "wan";
+ phy-handle = <ðphy0>;
+
nvmem-cells = <&macaddr_config_8>;
nvmem-cell-names = "mac-address";
};
+
+&mdio {
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
&switch0 {
ports {
- port@0 {
- status = "okay";
- label = "wan";
- };
-
port@1 {
status = "okay";
label = "lan1";
3 Likes
Thatās amazing news. I have a second C6 v3 that I will try this on when I get some time (probably in a few weeks)
If it does work then I would be more than happy to exchange a WPS button that I never use for improved routing capacity that matches the interface speed. Is there any likelihood that it might eventually make it into the official image list?
It depends on whether or not it works, first of all. I don't think this would be accepted as the default way, so you'd do it for your own use case.
Would the TP-Link ER605 v1 and v2 be compatible?
ER605 v2 devicetree already implements this so the answer is yes. I don't see ER605 v1 support on OpenWrt at all.
The hardware offloading page in the official ubiquity documentation indicates that ER-X-SFP is supported, but does not details if it only concerns some interfaces.
Is this an omission from their side?
edit: nevermind