root@lede:~# cat /sys/fast_classifier/exceptions NO_IIF = 76348 CT_NO_CONFIRM = 22356 TCP_NOT_ASSURED = 20573 TCP_NOT_ESTABLISHED = 414 UNKNOW_PROTOCOL = 1807 NO_SRC_DEV = 190 NO_DEST_DEV = 7811580 WAIT_FOR_ACCELERATION = 54399 UPDATE_PROTOCOL_FAIL = 414 CT_DESTROY_MISS = 58743
And what's your 1st string of debug_info output?
size=1899 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=0 done_fail=0
root@lede:~# cat /sys/fast_classifier/debug_info
size=73 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=0 done_fail=0
....list of ip address mac address etc...
As I dig deeper into fast-classifier more questions are rising. Have you verified if it actually gets invoked?
cat /sys/fast_classifier/debug_info shows a lot of tracked connections with none of them offloaded, connmark = 000000 and very low counter of hits. Connections size gets constantly rising with each new connection, but the code for freeing the connection entry and sfe_connections_size-- is never invoked... causing mem leak?
Another thing: cat /sys/fast_classifier/exceptions shows connections awaiting acceleration counter that also does not seem to decrease, only increases.
Is fast-classifier actually needed?
@gwlim I'm trying your build out on an Archer C7v2, but loading the fast_classifier module causes my SQM to stop working (or at least bufferfloat gets very bad). Any hints as to what I might be doing wrong?
Guys, what's about IPQ8074 (802.11ax)? Does lede/Openwrt support this chip? I notice Linux kernel got qcom.ipq8074.pinctrl support?
Fast Path doesn't mean you can use SQM on Gigabit.
If you set 900Mbps on SQM it is = to SQM Off because your Router still cannot process SQM at 900Mbps
On WDR4300v1 OC@730MHZ
cake+layer_cake = 571 Mbits/sec
fq_codel+simple.qos = 663 Mbits/sec
Definitely higher than no fastpath but not gigabit either
For this problem you can try overclocking your router if you want
Also I have tried dslreports too, on different web browsers I get different results.
At different time it connects to different servers and I get different results.
And I don't want to register for something as simple as a speedtest
So I will not take dslreports results too seriously
As long as I get consistent ping times in my games I am satisfied.
Hi @gwlim, I'm not testing it on a gigabit setting (my humble connection is 12/2.5mbps),
On dslreports, without fast_classifier, I get about 10.5/2.3 with low bufferfloat. Once I load the fast_classifier module, the connection goes to 12/2.5ish with large bufferfloat. I'm applying it to eth0 (which I think it's correct) with 11300/2300 kbps using cake/layer_cake, although fq_codel/simple gave me similar results.
If I load fast_classifier while testing on dslreports (modprobe fast_classifier in the middle of the test), it will immediately raise the connection speed and raise the bufferfloat. But I feel I might be doing something wrong.
You should be applying it to eth0.2 the WAN Interface
Also Fast Path saturate the connection quickly than SQM can process, I always got a hump in speedtest especially downloads.
In uploads it is fine.
Perhaps since you are on 12Mbps fast path does not do anything for you.
This is somewhat to be expected, given that this speedtest is HTML5 based and is pretty much executed in the browser. So different results on different browsers not noteworthy. The more relevant test is, do you get similar numbers when doing repeated tests (against similarly close servers)? Please also note the detailed results will also contain an estimate of the browser's speed and suitability for the test.
It picks the servers by default based on RTT/proximity and load, but if you do not want that, you are just one free registration away from selecting the set of servers from which your test should be served (so you do not explicitly pick the server, but you can restrict the set from which the test chooses). Oh you can also, and this alone puts the dslreports speedtest into its own category for open speedtests, select the number of measurement streams per direction. And potentially relevant to this topic you can set the test for 1Gbps+ speeds...
You can actually configure a lot of the tests's options even without a registration (I believe everything short of the test duration), just without a registration these changes will not be persistent.
Honestly, I am not sure, you actually looked that carefully at the test to begin with... 
Maybe it is worth your time to revisit some of these issues again?
Well, good point, as long as you have a relevant test for latency under load all speedtests basically become "toys"
Best Regards
Okay upon further investigation which connection manager manages the offload - fast-classifier or shortcut-fe-cm depends on which one is loaded first in modprobe squence. If you load fast-classifier before sfe-cm you'll notice offloaded values rising in debug_info and it really represents what's going on under the hood.
These 2 connection managers grab the same hook in dev.c and it seems that only 1 should be loaded at the same time. so it's better to test which one performs better.
According to source code sfe-cm is for offloading the bridge interface. Offloading nat is assumed to be done in fast-classifier. If you echo 1 > /sys/fast-classifier/skip_to_bridge_ingress it will also offload the bridge.
But that's not the case in your setup, fast-classified should be loaded without shortcut-fe-cm or before shortcut-fe-cm, otherwise you don't get nat offloading, because sfe-cm gets all the connections and passes it by if it's not a bridge interface...
Edit: seems like sfe-cm should be completely dropped... and in this case there is no need in so much netfilter modifications because there's only 1 listener left - fast-classifier. The code of fast-classifier should be adjusted as well to work with unmodified netfilter, but that's not a problem. This will be a more generic solution that may has a chance to get into upstream.
If you actually bothered to test you will know all 3 components are required to achieve Gigabit NAT for MIPS74kc AR9344 and above.
And fast-classifier has a dependency on Shortcut-fe-cm if you bothered to check the makefile.
The dependency is there for a reason.
Don't understand why are you second guessing the code when all you need to do is test the solution.
Ah, so that's your approach - if it visually works it doesn't matter what's really happening...
I'll remind what's happening:
That's not a single offlloaded connection that went through all the checks of fast-classifier driver. Why is all this combination working and providing such benefit - a question. Maybe it fully bypasses the kernel network stack as an undefined behavior.
But again it's up to you to use this as it is, but others should be aware that your solution is not working as as defined by the driver.
Instead of throwing words you'd better check the code. Current solution just lacks something and the defined result may not be as high.
And no, fast-classified does not depend on sfe-cm, it has shared header with sfe-cm, sfe and sfe-ipv6, but does not depend on sfe-cm. If you check the code fast-classified is a standalone and extended version of sfe-cm
1 Like
That is because debug is set to zero.
Not only do you have a wild imagination you also can't read the code
Oh my, that's pretty ignorant, point me to the code where setting debug to 0 disables those counters.
Those counters tick whatever debug is set to.
You can prove me wrong and set debug to 2 and check by yourself.
Look, I don't want to disregard your efforts, I just want to tell that there is something lacking to make it work as defined.
Edit: And if debug is set to 0 why do size and exceptions keep ticking? Or debug has a specific purpose to turn off only offloaded counters?
Edit2: just rmmod shortcut-fe-cm and you'll notice those counter start magically ticking.
1 Like
@gwlim, hmm, I've noticed the eth ports were configured as untagged in the switch. I've tagged them, but they still don't work when fast_classifier is loaded.
I'm aware that a 12/2.5mbps is not enough to need fast-path, but I'm enthusiastic about it nonetheless. But either way, it shouldn't affect the SQM working. Below is my switch config (relevant parts only).
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0t 2 3 4 5'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '1 6t'My data looks like this (without the 059-increase-ag71xx-tx-ring-size.patch):
[ root: ~ ]# uptime
11:47:41 up 2 days, 16:09, load average: 0.00, 0.00, 0.00
[ root: ~ ]# cat /sys/fast_classifier/debug_info
size=6 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=5 done_fail=4
[ root: ~ ]# cat /sys/fast_classifier/exceptions
NO_IIF = 131373
CT_NO_CONFIRM = 5043
TCP_NOT_ASSURED = 4991
WAIT_FOR_ACCELERATION = 14609601
CT_DESTROY_MISS = 66646So, I think @dissent1, you are right. I'll try out the rmmod mod tonight.
That's the way counters should look like, but with higher values.
These counters should be referred as successful
offloaded_fail=5 done_fail=4
It means: offloaded_fail - connections that has entered offloading state totally, done_fail - connection has been offloaded and already closed atm.
Don't be frustrated by "fail" sign in it. Due to code specifics, when connection gets offloaded, fast-classifier sends a debug msg to a userspace debug daemon (that is absent), and if the msg is sent successfully it increases 'offloaded' counter if the msg fails it increases 'offloaded_fail' counter. So 'fails' just refers to a debug msg.
Alas considering your device has been up for 2 days with a lot of connections, those counters should have been much more than 5.
According to my observations some rare packets get into the fast-classifier after sfe-cm, but not enough for it to decide to offload. Entry point for connection to get offloaded - 128 pkts.
root@lede:~# uptime 07:28:33 up 5 days, 11:16, load average: 0.04, 0.02, 0.00 root@lede:~# cat /sys/fast_classifier/debug_info size=49 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=1 done_fail=1 root@lede:~# cat /sys/fast_classifier/exceptions NO_IIF = 154627 CT_NO_CONFIRM = 57376 TCP_NOT_ASSURED = 36685 TCP_NOT_ESTABLISHED = 1959 UNKNOW_PROTOCOL = 616 NO_DEST_DEV = 50 WAIT_FOR_ACCELERATION = 123223 UPDATE_PROTOCOL_FAIL = 1959 CT_DESTROY_MISS = 87176
maybe five minutes after rmmod shortcut-fe-cm:
root@lede:~# cat /sys/fast_classifier/debug_info size=145 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=50 done_fail=7
maybe five minutes after modprobe shortcut-fe-cm:
root@lede:~# cat /sys/fast_classifier/debug_info size=59 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=80 done_fail=57
maybe ten minutes after that:
root@lede:~# cat /sys/fast_classifier/debug_info size=28 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=112 done_fail=106
maybe ten minutes after that (again):
root@lede:~# cat /sys/fast_classifier/debug_info size=43 offload=0 offload_no_match=0 offloaded=0 done=0 offloaded_fail=158 done_fail=141