A few more tests are made, it seems HW offloading is not working right after applying the disabling of flow control patch. The downloading throughput with HW offloading on is worse than it off, not only lower but not even as steady anymore.
Can someone confirm wether the HW offloading is connected with flow control in anyway, somehow?
BTW, the resource usage did down a lot with HW offloading on.
I have not tried it. I have stopped compiling 18.06.6 because i am testing the official build, and HW Flow Offloading must have some problems opening and/or keeping many connections or close it too fast because the P2P are very slow (especially when uploading). So now i'm compiling 19.07.0. I'd rather have a stable router, connection and performance than reach full speed.
Does that mean you don't care about HW Flow Offloading anymore, since 19.07.0 has bug with it?
In 19.07 it does not work at all, but in 18.06.6 it seems to have bugs, at least p2p does not perform the same as with the deactivated one. You say that it also does not work as it should with the patch, therefore i prefer to have 19.07 even if HW Flow Offloading is not working. But with the patch to disable flow control. For months i haved crash kernel errors and i want stability. I hope to get it with the patch. Of course when in the master branch or 19.07 HW Flow Offloading works, i will try it again.
What exactly do you mean by the possible bug in 18.06.6 regarding hw offloading?
There seems to be a patch that fixes HW Flow Offloading on 19.07+/master. I will prove it. https://github.com/openwrt/openwrt/pull/2815
Works for me on 18.06.8
I think 18.06.x doesn't need the patch. Only in 19.07.x and master.
I tested myself in 18.06.8 just now by running a speedtest and viewing the output of the top command while connected to the router in SSH, it seems every time I run a speedtest the "sirq" usage goes to 20% or so and idle goes to 80% or so, is this intended behavior when hardware flow offloading is on?
Edit: Hardware flow offloading seems to be broken in 18.06.8. When I downgrade to 18.06.2 and run a speedtest the CPU runs at 97-98% idle, as expected, instead of before where it would use 20% of my CPU when I ran a speed test.
I tested with 18.06.5, all the packets are processed by CPU, hardware flow offloading doesn't work even if you check it on. Right now I'm on 18.06.2 and it's working though, not sure if there's any newer version that it works on between 18.06.2 and 18.06.5
Interestingly. I thought that HW NAT worked on all 18.06.x. On 18.06.4 i think it worked, but i'm not sure.
It seems I made a mistake. Today I noticed even on 18.06.2, hardware offloading suddenly stopped working for me when it was working a few days ago. Then I realized that NAT6 was for some reason causing hardware offloading to stop working. I reflashed the latest 18.06.x (18.06.8) and now my hardware offloading is working flawlessly. If anyone is having the same problem as me and uses NAT6, try turning it off.
HW NAT i think not work fine with ipv6
Yeah it seems to be broken so I turned it off and now HWNAT is working great
A few hours later, even with no NAT6 installed this time, it seems to have reverted back to Software NAT
Finally the patch seems to be this: https://patchwork.ozlabs.org/project/openwrt/patch/20200526200102.15470-1-ynezz@true.cz/
Although i have not tried it yet. It was added on June 1 to the branch 19.07 and is included in the new release 19.07.4.
I have 19.07.4 installed now. I am seeing hardly any CPU usage (~2%) on a download speedtest (@ 500 mbit/s), but I do see a rather high load during upload speed test (roughly ~50% CPU load @ 500 mbit/s).
I am using a PPPoE connection in case that matters. Anyone with similar results? Previously (before HW offload even became broken) I had very little CPU usage % in both directions. Anyone seeing similar results?
@nbd Is it possible HW NAT offloading is still broken in one direction?
In theory it should be fixed in both directions even with PPPoE. I think it does not work well with IPv6.
Weird. Now the upload direction is offloaded as well. Not sure what's different. I will keep an eye on it and see if the bug returns, and if so, what seems to trigger it.
Hardware NAT now seems to be working in master with the DSA driver as well!
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4fb58813f94ac6cc8167138e23a92189fe50b258