Hi, I looked through your commits. Maybe I missed it, but are you using/integrating the 3 small patches for Baby-Jumbos support (MTU up to 2030) from here Batman on devices with DSA ... Various issues - #12 by LGA1150, that @LGA1150 pointed to? He also mentioned another patch further down-thread for another issue I was having with the MT7530, but that last one wasn't applying cleanly.
Im only focus is on the offload and disabling flow control, nothing else.
If you follow the https://openwrt.org/docs/guide-developer/toolchain/use-patches-with-buildsystem guide on creating a openwrt patch, you can then make a new patch in the 5.10-backports that will cleanly patch on build time for openwrt.
There will be some sort of manual fitting the changes, but its easy to understand from the link i provided.
You can then do a pull request to my gitlab, which i can then try and push upstream.
offtopic:
@db260179 patch for ipv6 have problem for merge on github?
15 days no change and not merged ...
I'm new on working on opensource projects. What is the steps to merge on patch?
Well, it looks like it needs to go to the netdev mailing list first, then will be backported to openwrt.
I haven't had the time to try and send an patch email to that netdev list. I find the mailing list a very antiquated way of doing things, so it will be a while, unless someone else can do it?
1 Like
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:
Wed Jan 26 16:46:57 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1
Wed Jan 26 16:46:58 2022 daemon.notice netifd: wan (2968): udhcpc: lease of 192.168.0.10 obtained, lease time 3600
Wed Jan 26 17:16:58 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1
Wed Jan 26 17:16:59 2022 daemon.notice netifd: wan (2968): udhcpc: lease of 192.168.0.10 obtained, lease time 3600
Wed Jan 26 17:46:59 2022 daemon.notice netifd: wan (2968): udhcpc: sending renew to 192.168.0.1
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?