curios to check if with nss offload ath11k consume less ram
and yes as i thought... with nss offload the ram is increased of just some mb under load and doesn't leak... so the """leak""" is from a bad implementation of the ring handling...
with nss offload I have 192mb used with max of 200mb with a speedtest
In short for QCA the slowpath is an hack and nss is the right way to handle traffic...
They are stuck in opposite day ahahahha
I have the same issue with my R7800 when fiddling with the ipq806x nss-ecm code. The router would register load when sitting idle. I traced it to nss-ecm using non-interruptible sleep APIs. That is for QSDK 11.2. I believe the same issue is still present for 11.3 and 11.4.
You can use this patch and test if the problem goes away:
Great, so 300MB used memory was not "normal" after all, even at QCA 
They just never tested slow path...
Btw, have you notced that the guys on stock has 402MB available memory, and on OWRT we only have 375MB? Wonder if the diff is coming from what robi said about ancient ath11k and NSS firmwares, or maybe the load can be further reduced by lowering the fixed reserves of the Q6? Is it possible to check the "utilization" of that?
The load indication of "uptime" is simply wrong, nothing is eating the CPU. "htop" shows the correct load values (barely any).
Anyway, can't wait to test your wifi offload patch, hope it will be pushed to robi's repo soon
The 40MB of difference is from the Q6 reserved space being 40MB smaller in stock FW as its using 512MB layout.
I am gonna change that today.
@quarky Thanks for sharing the fix for non interuptable sleep.
That is something that is gonna get tested and applied
WiFi offload is somewhere wink wink and public but I would like to test decap offload first...
Honestly, with decap I doubt that full offloading is needed at all.
the ram benefits are something to consider but wifi offload is like all the other things... very hard to merge in openwrt
I doubt that there will be RAM benefits, it only shifts processing the packets to the NSS.
WMI buffer and stuff like that is still handled by the kernel as kernel needs to see the packets before NSS can hook on.
With nss offload some crypto ring are actually disabled and the kernel doesn't have to handle them. That is the cause of the increased and growing ram and with nss offload the ram stay at 190mb and increase only with load (and it's freed right after)
I am gonna be honest to say that man hours that have to be spent on NSS offloading WLAN are not worth the saved RAM.
Anyway when i will have some time this summer, will try to waste some time and check if something can be improved about ram handling for ath11k.
Think it's time to concentrate on pushing the target to openwrt. What do you think? We reached a stable state from what i can see
Wifi looks to work (but we are missing 160mhz native support)
wired works (and we even have offload support)
we are missing ath10k support?
Yeah, I think we reached a point where it works.
After a cleanup round I agree on pushing it to replace the dummy ipq807x target, heck we are lucky that one already exists.
I have not tested 160MHz, it should work, and if it does not then we are gonna need to backport patches for that as there is a DFS one for 160Mhz in 5.12 and later for sure.
What part of ath10k are we missing?
IoT radio works with it.
hostapd for sure doesn't have support for he160 or we need to backport wifi patches if they actually pushed them
sorry didn't check ath10k state... Do we also have the led working?
Are you sure that hostapd does not support HE160?
It should have support for it for a while now.
There is a DFS patch for 160MHz in upstream ath11k.
Yeah, ath10k works fine, and IoT LED as well.
I used iwinfo and he160 was not displayed as supported... i think we are missing ath11k support in this case
can you link the patch so i can check if it's the native one from wlan-open?
iwinfo is not a good tool to use, its a OpenWrt project parser, if iw say that HE160 is supported then it is.
There should be 80+80 support as well.
BTW:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath11k?h=v5.13-rc4&id=788f805e8c0a10679fdfa7c6d0e21465e3b62de5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath11k?h=v5.13-rc4&id=096b625fab8f9d88d9b436288a64b70080219d4b
can't understand if this is needed
https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/204-ath11k-support-for-native-160MHz.patch?h=NHSS.QSDK.11.4
with 160mhz we should be able to reach 2+gbps?
I dont think it is.
Yeah, 2+Gbps should be doable in theory but note that it will go to 2x2 when 160MHz is used.
At 160MHz and 2x2 it should have the same 2.44G PHY rate as 4x4 when 80Mhz is used.
Its the limitation of the radio IC used.
Only AX9000 of the Xiaomi models can do 4x4 160MHz to get the 4.8G PHY rate as it uses QCN9024+QCN5054 at the same time to make a virtual 4x4.
That is at least how I understand it.
also there are many patch about a multiple bssid but i can't understand if it the special mode for the router that has 2 wifi 5g chip... We need to ask how it's handled by the standard firmware
lol 4.8g WHAT A JOKE....
think my laptop can handle only 2x2 160mhz
Its all handled by the firmware anyway, driver just tells it to do xyz frequency with control/center channels xyz.
Yeah, I mean its not even 5Gbits.
My phone should do 160MHz at 2x2, and I have an AX201 card that I can plug in one of the PCI routers lying around.