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.
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.
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.
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.
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.
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.
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!
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).