Qualcomm Fast Path For LEDE

[azuwis]

@nariox

I might be doing something wrong, but it seems to be working for me if I rmmod shortcut-fe-cm or rmmod fast-classifier (unloading either one is sufficient for me). Could you or @azuwis try this?

Only fast-classifier compiled and installed(as @dissent1 suggested), so I could not test this.

Did you confirm shortcut-fe was working when you rmmod shortcut-fe-cm or fast-classifier?

[dissent1]

Yes, it corresponds to what I have said

@dissent1

Yes, I'm pretty confident in that. Upon deeper digging into the code I can conclude that you should use either sfe-cm or fast-classifier. Fast-classifier is a clone of sfe-cm with additional functions and is preferable. It has some additional checks, adds statistics and allows bridge offloading as well:
echo 1 > /sys/fast_classifier/skip_to_bridge_ingress

These both modules shouldn't be used together because fast-classifier decides to offload when the certain connection hits 128 packets (you can adjust it with /sys/fast_classifier/offload_at_pkts), but sfe-cm does it at the moment, so packets don't go to fast-classifier anymore because the offloading rule is already created by sfe-cm. It's a race condition.

[mrmidnight]

@dissent1 I have been able to make successful builds on my own for the 7800 by combining your work with the Lede Master. Great work! I am on a 100M connection, before wireless I was only getting about 85-90M of that, and as of an hour ago I have been hitting 110M using WiFi and 115M using wired. Great job!

[dissent1]

The credit should have been gone to @gwlim, I've just adjusted the driver a bit - filled the missing parts into fast-classifier and will make it clean to make a pull request and see what devs think about it. It has a noticeable chance of not going upstream, because the driver is somewhat hacky - it bypasses a lot of kernel network stack, that's why it's so fast.
Btw if you are talking about Netgear R7800 - then it supports almost up to 1gbit wired and 500-600 mbit wireless with 80mhz width, so sfe shouldn't have caused much effect.

[dape]

@dissent1

It has a noticeable chance of not going upstream, because the driver is somewhat hacky

I think there are plenty cool hacky things already in OpenWrt/LEDE, don't worry much. Thanks again to both of you for these efforts, i am waiting myself for the LEDE inclusion so i can properly build it myself for my routers.

[mrmidnight]

I completely agree that it shouldn't have done anything, for some reason though it stabilized my connection, so once I hit that max speed it stays there. Latency lowered, and bufferbloat on ingress stayed low. I am talking about my R7800 on 80Mhz.

[nariox]

Sorry, nevermind. Upon closer inspection, you are right. The fast-classifier does stop SQM.
The shortcut_fe_cm doesn't, but I can't test whether it is doing anything because I only have 1 gigabit capable computer and 12/2.5 mbps connection...

[phuque99]

Does it make sense to add SFE and / or fast classifier to a low bandwidth connection when hardware is capable of routing at that speed? Router CPUs that can handle low bandwidth shouldn't need SFE, but instead requires SQM to prioritize bandwidth over a slow link.

On the other hand, 1Gbps fibre is harder to saturate constantly, making SQM less important. Instead SFE is required to help older SoCs keep up with the routing speed.

[azuwis]

While both are true in their own scenarios, but in some edge case, it's not. Because NAT, Wi-Fi, SQM are all CPU intensive tasks.

Let's assume ISP bandwidth is 100Mbit/sec, Netgear WNDR3700 can handle that in Wi-Fi and NAT. But it will drop to about 50Mbit/sec when SQM simple.qos script enabled. If disable SQM, bufferbloat appears.

If we can make shortcut-fe and SQM work together, we may be able to get full speed without bufferbloat.

[chros]

@gwlim: that patch seemed to be the problem, indeed, my C5 works fine without it for a week. Thanks!
Btw, I modified your wifi regdb patch, removed every restrictions from 00 region, now you can select every channel with it, even 14.
If you want I can create a pull request.

@all: and thank you 2 for all your work you have done! This is one of the most exciting feature in the last 10 years!
And thanks for all the testers as well!

[chros]

And you are right in this.

[moeller0]

Sidenote: I would rather not create and distribute a version that easily allows unexpecting users to run afoul the local RF regulations. Both the US regulator and the EU regulators are quite insistent that nobody accidentally or knowingly violates the restrictions to the tune of considering disallowing open wifi firmwares like lede, let's not give them easily exploitable justifications for their 'draconian' idea about how regulation should work, okay?

Best Regards

[chros]

Oh, I forgot about this completely. so that's why gwlim included the handicapped version in his repo. Now it makes sense. Thanks

[xssa]

@gwlim
Good work! Btw, have you tested 24k optimized images on 32M RAM equipped router? It terrificaly suffers from the luck of free RAM in my tests. MemFree; floating on 2500-3100 right after reboot and NAT or bridge speed has downspikes til 0.
On lede 17.01.2 oficial images MemFree is floating on 6900-7800 in the same conditions and no speed downspikes on NAT or bridge.
Can you explain some tuneups?

[etomm]

Hi, followed all the topic and took a look at the PR. It will never be merged without enough descriptions and explanations.

[yy0c]

It was discussed. Check here.

[xssa]

@xssa

@gwlim
Good work! Btw, have you tested 24k optimized images on 32M RAM equipped router? It terrificaly suffers from the luck of free RAM in my tests. MemFree; floating on 2500-3100 right after reboot and NAT or bridge speed has downspikes til 0.

This issue was resolved. Has to use -Os target optimisations instead of -O2

[r43k3n]

@dissent1

Yes, I'm pretty confident in that. Upon deeper digging into the code I can conclude that you should use either sfe-cm or fast-classifier. Fast-classifier is a clone of sfe-cm with additional functions and is preferable. It has some additional checks, adds statistics and allows bridge offloading as well:echo 1 > /sys/fast_classifier/skip_to_bridge_ingress

These both modules shouldn't be used together because fast-classifier decides to offload when the certain connection hits 128 packets (you can adjust it with /sys/fast_classifier/offload_at_pkts), but sfe-cm does it at the moment, so packets don't go to fast-classifier anymore because the offloading rule is already created by sfe-cm. It's a race condition.

gwlim page says that I need those three to make it work:

kmod-fast-classifier
kmod-shortcut-fe
kmod-shortcut-fe-cm

You are saying that I can actually have either the first two or the third?

[r43k3n]

@azuwis

One thing I noticed is shortcut-fe will break SQM, at last in my case with sch_cake.

ISP advertise the Internet bandwidth is 100M, and I was limiting my download speed to 80000K in SQM:

config queue 'wan'
option qdisc 'fq_codel'
option qdisc_advanced '0'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '0'
option itarget 'auto'
option etarget 'auto'
option linklayer 'none'
option interface 'pppoe-wan'
option upload '4400'
option script 'piece_of_cake.qos'
option enabled '1'
option download '80000'

Tested using iperf3 and ping:

SQM enabled, shortcut-fe enabled: iperf3 93.3 Mbits/sec, ping 21.8ms
SQM enabled, shortcut-fe disabled: iperf3 75.2 Mbits/sec, ping 6.0ms
SQM disabled, shortcut-fe enabled: iperf3 93.4 Mbits/sec, ping 18.3ms
SQM disabled, shortcut-fe disabled: iperf3 93.1 Mbits/sec, ping 18.4ms

Shortcut-fe enabled means modprobe fast-classifier, shortcut-fe disabled means rmmod fast-classifier.

Edit: Shortcut-fe only breaks SQM ingress, egress works fine.

Your SQM config is faulty.
You can't use fq_codel with piece_of_cake.qos

[r43k3n]

@azuwis

One thing I noticed is shortcut-fe will break SQM, at last in my case with sch_cake.

@azuwis

Shortcut-fe only breaks SQM ingress, egress works fine.

SQM doesn't work properly at this time with Fast Path?
It's a shame. I really need it.