Are you trying to use ath10k or the qsdk drivers? Those kind of bear resemblance to how madwifi looked back in the day
Using the ath10k driver for lede-17.01 branch.
Actually the patch is done for mac80211 and not the ath10k driver. The mac80211 driver was patched to use the NSS drivers to bypass the netfilter stack. Doing that reduces the load on the Kraits CPU, just like the nss-gmac driver. Anyway, that’s how I understand it.
I've uploaded my latest firmware build for anyone who has a R7800 and brave enough to try. You can download my builds here:
https://app.box.com/s/ykyzhbsc8s87qw5dkunv3cv3lv43z0vs
My theory of Krait CPU usage during WiFi transfer being caused by encryption/decryption computations appears incorrect. It looks like the qca9984 supports encryption/decryption of data packets in hardware. Looks like I need to dig further to identify where the CPU cycles are used during WiFi transfers.
In any case, I would love to have feedback on performance and stability of my R7800 firmware builds. So if you're trying my builds, or compiling your own firmware from my GitHub repository, I would love to hear from you.
1 Like
This applies to most of the wireless chips. En/decryption is done by the chips themselves.
@quarky
I would be happy to test it out for you on my EA8500 if you create a pull request on https://github.com/openwrt/openwrt/pulls
I also think you will also get a lot of feedback from the other developers there.
2 Likes
This will be tough. Unlikely for the maintainers to accept the PR that easily. My repo currently still not as clean as I would have liked. So more work needed.
It also need to be based on master.
Then there is a high chance of constructive comments and help
This would be even tougher. The NSS drivers are only tested against kernel 4.4, at least from what I can tell from the QCA QSDK repo. Applying it on 4.14 would require a lot of testing. Maybe it’s something I can try when I retire from my day job. Heh heh.
Will it work with DSA patches?
1 Like
Not familiar with DSA, but if I'm not wrong, it's for the Mediatek SOCs?
no, this is https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=commit;h=9b2f86fdbd59c0b54a958cc5d0097d785bea3bae patch, which enables qca8k support. For 4.9 kernel patch https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=commit;h=dd3bdac6d1dcd98d4d494052f7df31ca21558d6f
Thanks @neonman63
From the links, it looks like it's a replacement for the ar8xxx switch drivers. In theory the NSS drivers should work with DSA then, as the changes required by the NSS drivers does not touch the switch drivers.
But the DSA codes are for the 4.9 and 4.14 kernels, which I suspect the NSS drivers will not work correctly, if at all. The NSS drivers needs extensive patches to the Linux kernel networking stack, and the drivers are currently only tested against the 4.4 kernel changes.
Right now, I'm still struggling with the 4.4 kernel, trying to make it stable enough for use. Still encountering random reboots. Can't tell if it is caused by existing code, the NSS drivers changes or both.
I have been running this build of your firmware and overall am very impressed with it. By far the fastest iperf results I have seen from my R7800 among any firmware I have tried. I'm currently using my R7800 as an AP only, but I do perform backups over WiFi to my (gigabit-capable) NAS, so the performance of your firmware has been terrific.
However, I am having an issue where after the R7800 has been up for a number of hours, a small portion of my 5ghz wireless devices start dropping packets for several seconds before picking back up again. I'd be glad to offer up additional details if desired, but ultimately I wanted to ask if 1) are you still developing on this firmware? and 2) if so, do you have any newer builds I could try out?
Either way, fantastic work on this and I really appreciate your efforts!
1 Like
@_FailSafe you tested the firmware with the qca-nss drivers? If you did, was it stable for you, other than the 5GHz wireless issue? If your R7800 is stable, it is good news.
When I tried to use the NSS enabled firmware; although it gave a big boost to the routing performance of my R7800; it was unfortunately not stable. I can't understand why at the moment. When I tested the firmware in my test environment (using DHCP WAN), it was stable. When I put it into 'production' use, using PPPoE WAN, it became unstable and reboots randomly. My 'production' setup includes WireGuard VPN tunnels and PBR routes. I don't think it would cause the random reboots tho.
As for the issue with 5GHz wireless you are facing, it could be due to the QCA9984 firmware used in my builds. I'm trying to clean up my build environment and just stay with the lede-17.01 branch, adding just the changes required for the qca-nss drivers.
You may want to try changing the wireless channels and see if that solves your wireless issue.
And yes, I'm still trying to make my R7800 stable with the NSS cores enabled. The R7800 should run with the NSS cores enabled. I haven't paid much attention to the R7800 lately due to work, but I should be re-starting soon.
may i ask what are we talking about?
is it something like +20% or a proper boost to manage, for example, a gigabit connection?
sadly i'm far from being able to help on this, but i keep looking closely to this topic 
thanks a lot
You may refer to the figures I posted a while back here:
With the NSS cores performing the routing tasks, the Krait CPUs is basically sitting idle and it can be used to perform other tasks, e.g. VPN tunnels.
amazing.
so amazing, that i wonder why guys with a big brain and a magic touch like @Ansuel or @hnyman are not working on this 
Thank you a lot, my 7800 is indeet quite busy with ancillary tasks, this would be a revolution
The other thing that will be good is crypto in the NSS cores accelerating wifi encryption
in short this is for kernel 4.4... but there are lots of changes between 4.4 and 4.14
some times ago i made the code compile on new kernel but didn't actually works... and then i stopped working...
It seems that the QCA9984 chipset with the closed source firmware is already doing the encryption/decryption of WiFi packets on-chip. The NSS crypto capability doesn't look like it's being used for anything for the factory firmware. Once I get the NSS cores stable enough for routing tasks, I'll probably look into the crypto functions.
1 Like