MT7621 - 21.02/Master feedback firmware image test - IPV6 offload and disabled Flow Control

The very next message in the thread I linked was me describing successfully doing just that. With a link to a ready-to-use patchfile, that applied cleanly on r18612 master from yesterday.

So, I'll probably just try with cherry-picking your

commits, that seem to contain the meat of the changes.

Ok, wasn't sure what you where getting at?, but yes, feel free to cherry pick my changes.

Ideally get them pushed to upstream so everyone can benefit these fixes.

Also look at https://gitlab.com/db260179/openwrt-base/-/commit/098341f8c501b6a0796c73fb89e1eebac72c0ca9

I did for 21.02 branch, and just use the ifdef statement so its specific to the mt7621 soc on the master change. More likely to get added to mainstream if it only affects soc mt7621 devices.

2 Likes

I have several MT7621 devices, and run into problems with them one-after-another attempting to integrate them into Batman mesh networks, using wired and wireless links. One of the problems was crippled MTU-settings, that forced fragmentation on all backhaul packets, if wanting to keep 1500 for the payload LAN MTU. Then there were the problems with IPv6 traffic disappearing, the CPU SOC port loosing 16% performance, because the PHY is not correctly set to trgmii without 2 trivial DTS-patches. On top of that there are the ton of changes/regressions with DSA w.r.t LACP, VLAN-aware-bridges. I currently cannot add a switch.VLAN# interface to a bat0 master, thus using a specified VLAN for wired backhaul becomes impossible.

So I have been on the lookout for others maintaining/collecting patches for the MT7621/MT7530, that have somehow been forgotten. And your patches looked more complete than mine, so I thought, you had maybe integrated the MTU/TRGMII patches too.

Oh, and thanks for the link to the FC-patch with surrounding IFDEFs.

From my understanding, the bottleneck in the router is actually the firewall, not from the NAT functionality. NAT basically just replaces source/dest IP and port and let the packet flows thru. It is the firewall rules that slows down packet thruput.

The implementation of the flow offload solutions, whether it’s the Linux native solution or from QCA fastpath basically skip the firewall (or more specially netfilter) rules for established connection. For hardware NAT, it’s basically the same. It’s only enabled for established connection and it has the necessary lookup to replace the IP and ports.

So in short, IPv6 with firewall will see the same slowdown. Probably a tad slower since IPv6 packets have higher overheads.

Could you share your current mtu backport fixes?, i would like to add to my gitlab repo.
Thanks

1 Like

Here is the link to the pastebin: https://pastebin.com/79iW2TLY

I basically concatenated the 3 patches LGA1150 mentioned in this post, adapted some line offsets, and presto! MTU up to 2030 now works on eth0.

The patches seem to be from DENG Qingfang, and they were upstreamed into mainline back in late 2020, so maybe just after 5.10, that's why I'm closely following Ansuels PR for 5.15 support.

LGA also mentions a MAC learning patch a few messages further down, but I didn't use it yet. Had some issue with it. Will check again. Was hoping 5.15 makes that go away too.

2 Likes

I've added your patches (and cleaned up a bit) for jumbo support and added a few more features.

Not sure if the cpu learning needs anymore patches to work?

There is a lot of core DSA changes that would need backporting, it would be better if openwrt just go to 5.17.

Anyway here is my commit - https://gitlab.com/db260179/openwrt-base/-/commit/e7f1d0862ab25d52e4fb798d186ee4bdc8f255db

4 Likes

I may have misunderstood something somewhere, but I was under the impression, that OpenWrt would only use LTS kernels in their supported releases, at least until the OpenWrt specific patches are down to a more manageable size. So It would seem, that we'll be "stuck" with 5.15(+backported_patches) for a while.

1 Like

Ok in this situation is need list steps supported and not supported:

MT7621(PPE) + MT7530(Switch):
Upstream:

  • (PPE) Routing offload (ipv4)
  • (PPE) HW nat (ipv4)
  • (PPE) HW pppoe
  • (Switch) Bridge offloading
  • (Switch) Mirror ports support
  • (Switch) Vlan offloading

Patchs:

  • (PPE) Routing offload (ipv6)
  • (Switch) Disable flow control Workaround
  • (Switch) Baby Jumbo Frames on cpu port (2030 Max)
  • (Switch) Setting ageing time and assisted learning on cpu port

Not supported:

  • (PPE) NAPT+HQoS

@db260179 Help my on organize work ...

2 Likes

Yes this is true, for me there is a lot of work to keep backporting changes from newer kernels.

Entry point for submitting new backport patches is a lot of work.

Its going to take the openwrt community to keep bothering the gate keepers to backport these patches.

Alot of work now from openwrt is done by the main upstream sources, which is the correct way to do things, but takes patience and time.

Would be nice to have a couple of people with experience in patches and submitting upstream to keep an eye possible patches and submit.

Im doing this in my free time, as i have a need for these devices to work properly.

3 Likes

I had this problem on Xiaomi 3G v1 when I flashed OpenWRT 21.02 on it.

I downloaded firmware named "openwrt-21.02-snapshot-r16437-bb4c1de7ac-ramips-mt7621-xiaomi_mi-router-3g-squashfs-sysupgrade" from OPs google drive link and did sysupgrade via the web interface. When asked do I want to keep my current settings I said I do.
Was that right thing to do?

About 20 hours later I did not get a single LINK DOWN LINK UP error. Thanks DB.

EDIT: Speedtest results if that matters https://www.speedtest.net/result/12664306905

2 Likes

Hey, checking in again. I saw that the firmware was updated back on the 30th? Should we be using that, or are you planning on another release soon? I'm also seeing some waffling from folks on using 5.4 vs 5.10 kernel with this fix. Thanks!

Ok it seems I am no longer getting error in question, but I noticed something odd:

  1. Wed Jan 26 16:46:57 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1

  2. Wed Jan 26 16:46:58 2022 daemon.notice netifd: wan (2968): udhcpc: lease of 192.168.0.10 obtained, lease time 3600

  3. Wed Jan 26 17:16:58 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1

  4. Wed Jan 26 17:16:59 2022 daemon.notice netifd: wan (2968): udhcpc: lease of 192.168.0.10 obtained, lease time 3600

  5. Wed Jan 26 17:46:59 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1

  6. Wed Jan 26 17:47:00 2022 daemon.notice netifd: wan (2968): udhcpc: lease of 192.168.0.10 obtained, lease time 3600

System log is filled with those lines: https://pastebin.com/c0XDkWq1

Any idea what is it? And is it something to worry about?

1 Like

That is normal background chatter between your ISP's dhcp server and your (u)dhcp client on the router (WAN), lease time of one hour (assigned by your ISP) implies half-hourly renewals (half of the maximum lease time).

1 Like

No plans on any further changes. Just needs to go upstream now.

1 Like

Thanks. Any plans to do another updated pair of builds before the upstream fix, or are you making headway on that?

Good morning.

On start of day, DENG Qingfang send several commits for fixes on MT7530

(All list of patchs)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037805.html

(Jumbo frame, MTU 2026)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037806.html

(Add support for set ageing)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037807.html

https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037808.html

(hw offload for multicast on switch)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037809.html

(possible fix for rx/tx problem)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037810.html

(PHY link change irq)
https://lists.infradead.org/pipermail/openwrt-devel/2022-February/037811.html

@db260179

3 Likes

@eduardo010174 Thanks for noticing this patch set.

When i get some time will backport to the 21.02 branch on my repo, then everyone can test it.

Adding PHY support should help with port negotiation, not sure it will fix forced flow control though?

4 Likes

Ok new to this thread. what is the current best working version? I have a D-Link DIR-1960

With VLAN patches the upload speed stucked at 100Mb instead of 1Gb.

[65961.473728] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off
[65961.481419] br-lan: port 1(lan1) entered blocking state
[65961.486670] br-lan: port 1(lan1) entered listening state
[65965.775047] mt7530 mdio-bus:1f lan1: Link is Down
[65965.780251] br-lan: port 1(lan1) entered disabled state
[65967.848922] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off
[65967.856614] br-lan: port 1(lan1) entered blocking state
[65967.861839] br-lan: port 1(lan1) entered listening state
[65976.054938] br-lan: port 1(lan1) entered learning state
[65984.374771] br-lan: port 1(lan1) entered forwarding state
[65984.380182] br-lan: topology change detected, propagating
[65986.515766] mt7530 mdio-bus:1f lan1: Link is Down
[65986.520609] br-lan: port 1(lan1) entered disabled state
[65999.413392] mt7530 mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[65999.420971] br-lan: port 1(lan1) entered blocking state
[65999.426209] br-lan: port 1(lan1) entered listening state
[66008.054265] br-lan: port 1(lan1) entered learning state
[66016.374086] br-lan: port 1(lan1) entered forwarding state
[66016.379539] br-lan: topology change detected, propagating
iperf3 -c 192.168.1.1 -n 200m
PC->MI-R3P
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.30 port 45512 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  12.4 MBytes   104 Mbits/sec    0    106 KBytes       
[  5]   1.00-2.00   sec  11.2 MBytes  93.8 Mbits/sec    0    153 KBytes       
[  5]   2.00-3.00   sec  11.2 MBytes  93.8 Mbits/sec    0    116 KBytes       
[  5]   3.00-4.00   sec  11.2 MBytes  93.8 Mbits/sec    0   96.2 KBytes       
[  5]   4.00-5.00   sec  11.2 MBytes  93.8 Mbits/sec    0    209 KBytes       
[  5]   5.00-6.00   sec  11.2 MBytes  93.8 Mbits/sec    0   99.0 KBytes       
[  5]   6.00-7.00   sec  11.2 MBytes  93.8 Mbits/sec    0    119 KBytes       
[  5]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    140 KBytes       
[  5]   8.00-9.00   sec  11.2 MBytes  93.8 Mbits/sec    0    127 KBytes       
[  5]   9.00-10.00  sec  11.2 MBytes  93.8 Mbits/sec    0    130 KBytes       
[  5]  10.00-11.00  sec  10.8 MBytes  90.2 Mbits/sec    0    107 KBytes       
[  5]  11.00-12.00  sec  11.7 MBytes  97.9 Mbits/sec    0    120 KBytes       
[  5]  12.00-13.00  sec  11.2 MBytes  93.8 Mbits/sec    0    119 KBytes       
[  5]  13.00-14.00  sec  11.2 MBytes  93.8 Mbits/sec    0    105 KBytes       
[  5]  14.00-15.00  sec  10.7 MBytes  89.7 Mbits/sec    0    105 KBytes       
[  5]  15.00-16.00  sec  11.7 MBytes  97.9 Mbits/sec    0    127 KBytes       
[  5]  16.00-17.00  sec  10.8 MBytes  90.2 Mbits/sec    0    150 KBytes       
[  5]  17.00-17.78  sec  9.05 MBytes  96.7 Mbits/sec    0   90.5 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-17.78  sec   200 MBytes  94.3 Mbits/sec    0             sender
[  5]   0.00-17.79  sec   199 MBytes  93.8 Mbits/sec                  receiver
MI-R3P->PC
root@MI-R3P:~# iperf3 -c 192.168.1.30 -n 200m
Connecting to host 192.168.1.30, port 5201
[  5] local 192.168.1.1 port 1812 connected to 192.168.1.30 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  56.2 MBytes   472 Mbits/sec    0    368 KBytes       
[  5]   1.00-2.00   sec  49.5 MBytes   415 Mbits/sec    0    303 KBytes       
[  5]   2.00-3.00   sec  48.8 MBytes   408 Mbits/sec    0    379 KBytes       
[  5]   3.00-3.88   sec  45.4 MBytes   433 Mbits/sec    0    337 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.88   sec   200 MBytes   432 Mbits/sec    0             sender
[  5]   0.00-3.89   sec   199 MBytes   429 Mbits/sec                  receiver