Are you sure the drv is doing the same?
From what I can see, the normal function reschedule the packet to be handled...
The callback function overwrite that and just send the packet in the normal way... That I really think it's better since if it was rejected, it's invalid, if the nss queue is full then it's not that bad that also the cpu are used to handle packet.
Am I wrong?
Anyway for everyone else... the new changes should improve wifi traffic, most of the improvement in upload. (in theory the workqueue implementation should use both core to send packet to nss and use a queue to handle the packet to send) (it's very VERY similar to quarky implementation and also mimics the current implementation of the driver that try to send packets in bulk)
(tl;dr very similar to quaky and try to address the slow of the nss forward by queue the packet without locking the mac80211 driver)
Loaded the experimental wifi and latest NSS simplification commits. Rebased off master (was current up until just before the latest 5.4.72 kernel update).
R7800 doesn’t fully boot (flashing white light, nobody is home). Saved via tftp with my previous 20201019 build.
Don’t have any logs... not tremendously useful for you. For some reason the kernel is not liking one of the recent commits.
Must be because of something in master... i got the same flashing light today, had to do the tftp method to go back to an earlier master build.
Someone should alert the devs, I have no serial access to the router so I can't tell what's wrong.
@Ansuel Hi, Ansel. I'm sorry to disturb you.
Can you fix the options that cannot be built in qca-nss-clients?（kmod-qca-nss-drv-capwapmgr，kmod-qca-nss-drv-map-t，mod-qca-nss-drv-pptp，kmod-qca-nss-drv-pvxlanmgr）
OpenWrt SNAPSHOT r14738+69
the router booted and, by now, i can see no difference in wifi performance or cpu usage (i still haven't tried 160MHz channel width).
My problem is that i'm getting a "Error No related RPC reply" trying to access luci under nginx.
for sure not related with nss, but a problem for me
sorry you are right. just fixed in nginx conf.
Btw, the new version seems as good as previous one in normal usage, sadly with just top and my line (100Mbps upload) i can't check anything special.
Do you need some specific test?
thanks, amazing work
Compiled the code this morning (with the 5.4.72 kernel) loaded it up and I can tell you this is so far the fastest I've seen with my laptop over the wifi (sirq was 49 for download and 43 for upload):
All the test performed with speedtest_net tools to the same area/provider. This might add some inaccuracy, but I did multiple tests and they were pretty close.
The build seems to be stable - in the past multiple tests over wifi would crash the router.
The tests were occasionally showing fluctuation in the performance, but that might be just normal congestion, etc.
in my case, i had to switch to CT version to get this performance
with normal drivers i could not get anything from 160MHz channel width and i have not clients fast enough with 80MHz channel
but i saw now also ct seems good with iot devices, i could stay with them..
