Qualcomm Fast Path For LEDE

Hi. I have router tp-link wdr-3600. Actually, it's installed Dd-wrt. I'm thinking to install LEDE. I discovery this forum. It's great work.
How is this stable devoloped version?
I will use at my principal router with minidlna and transmission. Any problems?

Thanks for all!.

(Excuse me my english)

This thread is focused on discussing fast path patch for LEDE. Feel free to search the forum; or start a new topic if you wish to talk about just your router.

Hi.
I think I did not explain myself correctly.
I want to install the gwlim firmware on my tp-link wdr3600 router and thus participate in the tests that you do on the speed lan-lan and wan-lan.
But I want to make sure that this development version is stable enough and I can install any package like trasnmission or minidlna.
I could be a good beta tester.

regards

Just try it im always running the latest master versions in for my home lab its super reliable for me.

Posting in an epic thread.
Not sure if it's been mentioned before in this huge thread, but Fast Path will override any SQM instance ingress/egress shaping.
By the way amazing job @gwlim.

1 Like

It doesn't override with my patchset, but such traffic is not accelerated then.

@dissent1 Just double-checking. SQM would override fast-path even when i set sqm to eth1.2 only.

1 Like

Good question, i'm a little confused about SQM (cake) and fast-path, i thought they were mutually exclusive.

@gwlim

Hi, If I apply your 9xx-SFE-patches would it work on Linux 4.9 Marvell Kirkwood devices as well? Does SFE works on SQM-cake?

@gwlim - latest update 17.01-SNAPSHOT (hostapd and other "firewall and wifi") = your some patch from SFE block not patched kernel = toolchain global build error...
make -j1 V=s: http://wklej.org/id/3271970/
nf_conntrack_ecache.c.orig: http://wklej.org/id/3271973/
nf_conntrack_ecache.c.rej: http://wklej.org/id/3271976/

Thank you for all this marvellous work. I used the september image and I experienced a huge speed increase on my Archer C7 en TP 4300. One question: will there be an 17.01.04 image update for fast path?

1 Like

Seems this have been picked up by Ubiquiti as well, they've shown interest but not sure how will it turn out:

Cheers.

I've rebased dissent1's open Fast Path PR on github on master, built an image to my Archer C2600 and flashed it, booted and working fine.
Did a few iperf tests with various configurations. Fast-classifier seems to be faster than shortcut-fe-cm, improved NAT speeds in both directions compared to mainline LEDE by 10-45% depending on the test case (number of threads, direction).

Tried it on my EA8500 honestly I didn't see any difference at all. Tried it with -t 10 -P 10 it has the same CPU utilization both with or without SFE patch. How did you get the your benchmark?

I tried it with this one. https://wiki.openwrt.org/doc/howto/benchmark.nat

I've used iperf3.
Did you check if the kernel modules are properly loaded and SFE is working correctly?
lsmod should return the list of currently loaded kernel modules. It should contain shortcut_fe and either fast-classifier or shortcut_fe_cm.
If they are loaded, you can get some debug information about the offloaded connections with the following commands:

mknod /dev/sfe_ipv4 c $(cat /sys/sfe_ipv4/debug_dev) 0
cat /dev/sfe_ipv4

New to all this and followed these instructions to apply the SFE patch to Development in order to compile firmware with SFE for an EdgeRouter ERX:

*Add SFE to Development
git clone https://git.lede-project.org/source.git lede
cd lede
./scripts/feeds update -a
./scripts/feeds install -a
wget https://patch-diff.githubusercontent.com/raw/lede-project/source/pull/1269.patch
patch -p1 < 1269.patch
Make defconfig
Make menuconfig
*Before compiling with Make I selected my router and just toggled these options: Kernel Modules > Network Support > kmod-fast-classifier and kmod-shortcut-fe

How would you do the same but to Stable or the 17.01 branch? From what I have read in this thread you need to do something to remove the 4.9 modifications applied from the SFE patch but I have no idea how to do that. Thanks.

Edit - I figured it out. I cloned the source on my local machine and checked out 17.01. To get it to compile, I copied the three sfe patch files from hack-4.4 to patch-4.4 directory and it compiled just fine.

1 Like

git clone -b lede-17.01 https://github.com/lede-project/source.git lede

Well, finally I did it by myself. Just applied @dissent1 PR to latest 17.01.4 on my DGND3700v1/3800B. I'm still far away from the gigabit target but after a short speedtest I can say that I moved from a clearly capped 187/187 megabits of peak bandwidth to something like 310-245/200 out of 930/200 I can get by my ISP gateway. Without the SFE I got the core #1 fulled at 100% load while the #2 remained around 75% for the entire duration of the test. With SFE patch applied I can see both cores fully loaded during the download bandwidth test.

I am trying to compile the gwlim version but it gives me the same problem when patching the Linux kernel with patch 895. Let's see if I correct the patch 895 and get the image.

I have isolated this issue.
If you are still wondering
It is due to this patch
Nlbwmon does not comply to hardening of Stack

diff --git a/config/Config-build.in b/config/Config-build.in
index e0889fc..a6478fe 100644
    --- a/config/Config-build.in
    +++ b/config/Config-build.in
    @@ -31,7 +31,7 @@ menu "Global build settings"
     
     	config SIGNED_PACKAGES
     		bool "Cryptographically signed package lists"
    -		default y
    +		default n
     
     	comment "General build options"
     
    @@ -178,7 +178,7 @@ menu "Global build settings"
     	choice
     		prompt "User space Stack-Smashing Protection"
     		depends on USE_MUSL
    -		default PKG_CC_STACKPROTECTOR_REGULAR
    +		default PKG_CC_STACKPROTECTOR_STRONG
     		help
     		  Enable GCC Stack Smashing Protection (SSP) for userspace applications
     		config PKG_CC_STACKPROTECTOR_NONE
    @@ -196,7 +196,7 @@ menu "Global build settings"
     
     	choice
     		prompt "Kernel space Stack-Smashing Protection"
    -		default KERNEL_CC_STACKPROTECTOR_REGULAR
    +		default KERNEL_CC_STACKPROTECTOR_STRONG
     		depends on USE_MUSL || !(x86_64 || i386)
     		help
     		  Enable GCC Stack-Smashing Protection (SSP) for the kernel