@blogic TL-WDR4900 also has ar8327 inside.
I can test it.
If I understand correctly, fastpath can be tested here:
But how do i test hardware-NAT acceleration?
For the TL-WDR3600 is faster than fast-path, which relies on software optimization.
Can I test hardware acceleration on the TL-WDR3600?
Kind regards,
You cannot. LEDE/OpenWrt simply doesn't support HWNAT, or you can use stock firmware.
This is true, and this is exactly why they are working on it, and we must appreciate their awesome work so far.
Just following up on this, I'm working on porting the NSS-HOST (specifically NSS-QCA-ECM and co) stuff over from QSDK for IPQ806x platforms such as the R7800.
NSS-QCA-ECM is interesting because, from what I've read, it hooks into the Kernel and takes care of making rules for the NSS cores built into the IPQ ARM CPU and offloading to them where possible.
I'll keep you all updated.
3 Likes
Right, got qca-nss-drv, qca-nss-gmac and qca-nss-ecm compiling after cherry picking a whole heap of patches from the QSDK tree, however, I'm now seeing this and have no idea how to resolve, any ideas @dissent1?
Package kmod-ipt-ipopt is missing dependencies for the following libraries:
nf_conntrack.ko
It may be a dumb guess, but seems like you are missing relative module 
maybe it’s compiled but not installed?
Yeah, thinking the same, need to make sure all the various options are set in the kernel config really.
1 Like
It’s not kernel config, it’s package/kernel/linux/modules/netfilter.mk
aha, awesome, thanks for the pointer ... I've gone from knowing nothing about the OpenWRT/LEDE buildsystem to knowing more than I ever thought I would in only a few days ... good fun
Is there any chance to see hardware NAT on a future release of LEDE?
You have to distiguish between the different approaches used to accomplish this (not all of which are technically hardware NAT, but still serve the same purpose of speeding up WAN to LAN throughput).
- what is typically referred to as hardware NAT by the OEM firmware (involving only partially open, device specific code). No, this has basically no chance to be be merged.
- QCA fastpath, which makes up the laters parts of this thread, is relatively hardware agnostic and basically employs heuristics to bypass large parts of the kernel's network stack in cases it deems safe. Due to the fact that it isn't tightly coupled to very specific hardware or ancient kernel versions, this has a slightly better chance of being merged. But, this is still a huge amount of code, which is placed into extremely sensitive code paths and has basically zero chance of getting merged into the upstream kernel, where it would also get further auditing and scrutiny.
- new DSA based drivers under development for common switch hardware (qca8k, mt7530-dsa), which are a clean re-implementation of hardware acceleration within the upstream kernel framework. These have a rather good chance of getting merged (upstream and for LEDE), once the remaining bugs have been fleshed out (these will also profit from the pending support for multiple CPU ports for the DSA framework in the future) and after a conversion strategy for the switch configuration has been added. This likely needs a bit more time.
5 Likes
Which of the QCA modules provides fast-path or hardware assisted bridging. Um using 5 TP-link C2600s as APs in my home. Looking to get full throughput from Wireless to Wired LAN.
wireless to LAN has to go through the CPU anyway, so NAT doesn't hurt much.
Where Hardware NAT is the most useful is when you are going from LAN to WAN and
you can have the NAT done by the switch and the packets never touch the CPU
David Lang
I dont need hardware NAT. I have a sufficiently powerful router upstream that can handle gig+ NAT.
I just need bridging to go full stream.. Im only able to get about 650-700mbit over wireless at the moment with 100% CPU.
How are people getting SSDK to compile against newer kernels since switch.h include doesn't carry the required functions anymore?
I've been able to create an image from gwlim's repo on v17.01.4 and I wanted to know if I can relay on the stock's version repos for addons such as nfs and usb storage support?
I have noticed that if I am backing up a laptop to a NAS drive (both connected to Ethernet ports), the WAN/Internet traffic on my TP-Link wdr-3600 LEDE v17.01.4 for other wifi clients slows down. I understand that there is no official hardware NAT support and I am willing to give it up for other benefits of LEDE, But If I get a dual core router like Archer C7 with LEDE, will it alleviate this problem? I do not see CPU utilization going up during the transfer. I am not sure where the bottleneck is, but it certainly slows down the WAN/Internet traffic.
Be aware that C7 is only a single core ~750/775 Mhz mips, almost just the same as wdr-3600 but with AC wireless, the switch should do the traffic without affecting the wireless clients