https://github.com/gwlim/Openwrt_Firmware/tree/master/Fast-Path/Jun-2017/TP-Link%20WDR4300v1
I also tried it. Device is Buffalo WZR-HP-AG300H.
The summery of specifications:
SoC: Atheros AR7161 (680MHz)
RAM: 128MB
WAN/LAN: 1Gbps
FastPath off:
[ 3] 0.0-10.0 sec 390 MBytes 326 Mbits/sec
FastPath on:
[ 3] 0.0-10.0 sec 756 MBytes 633 Mbits/sec
We also began verifying with other devices.
It is an implementation that is not HW Accelerator, so it seems that the difference opens with SoC clock as expected.
I will check on ramips (MT7621) from next time.
I am particularly interested in scaling in the SMP environment.
Also, I would like to clarify that it is not dependent on HW, that it will running even if it is not a Qualcomm SoC.
1 Like
Could you please let us know once you have tried this? Would love to run this on my DIR-860L device as well 
Thanks i Will try when i get home and let You know.
I wonder what's the drawback of all these stuff... It's too good to be true.
Besides if it is really as good inside as outside it would have gone into upstream kernel already.
i couldn't say as i haven't done much testing and don't have the equipment to do enough. so, as much as i know: it's only improved my local link significantly and i've not ran into any issues yet with my current setup. maybe nobody wanted to port this over because of things @gwlim has already stated for their self.
..maybe this also goes for other people not wanting to do it because they didn't see a point to do this for other reasons.. upgrading router = better without developers having to use their time on old hardware..
it's maybe more of a rare case when something this big is ported by someone and gives this much performance but still, since someone has done the work it could potentially still be accepted but it would require more that might not happen that soon, we will have to wait and see.
also could be the case, "for kernel 3.x only" .. either way i just believe nobody wanted to spend time on this but @gwlim wanted to and shared it with us, so im just thankful for that and will keep following this thread.
1 Like
1 Like
I don't understand, why are you adding sfe driver with patch 896 into src and then cloning it from qsdk repo?
Cloning the repo from that branch seems to only add three package Makefiles, one init file and one script. No actual sources are cloned...
Looks like the whole clone step is largely unnecessary, as the package Makefiles could just be added to the main source. (Currently the Makefiles are first "cloned" and then modified with 899. Patch 899 could/should create them at one step.)
Ps. Netgear has apparently used that shorcut-fe in the OEM R7800 firmware: https://github.com/paul-chambers/netgear-r7800/tree/master/package/shortcut-fe
That's not mine
Yeah, that's exactly unnecessary - unnecessary is adding the driver with patch, it's better to clone from QSDK only as it has newer sources with sqm added. And more recent branch should be used - release/endive_cc
https://source.codeaurora.org/quic/qsdk/oss/lklm/shortcut-fe/log/?h=release/endive_cc
There are even more fixes and valuable changes here
https://source.codeaurora.org/quic/le/platform/vendor/qcom-opensource/shortcut-fe/log/
What are the odds of this eventually ending up in the LEDE master branch? And if it does, in what kind of timeframe?
The question is what does NOT work with these patches. I will look more deep there.
What about bridging, vlans, ipv6, iptables, etc?
1 Like
And if it affects security...
Those cases are covered in
https://source.codeaurora.org/quic/le/platform/vendor/qcom-opensource/shortcut-fe/log/
https://source.codeaurora.org/quic/qsdk/oss/lklm/shortcut-fe/log/?h=release/endive_cc
Unfortunately development of this driver is highly decentralized, so one should pack it together
Hard to say, but I would say 50% probability that it gets included at some point. Some network stack core developer should get interested to make that happen...
The "easy" part is writing the packages themselves, but the more problematic part is that it requires some modification to the network stack. E.g. netfilter and Linux net/core/dev.c need to be patched and a possible change would affect all users (eveb those who do not use the optional new kernel package).
Works and stable with vlan's, thanks You.
1 Like
Sorry to jump into the discussion. I was having trouble building from gwlim's version (unpatched built fine), it seems like the trouble was using GCC 7 to build GCC-mipsel 6.3 (tried removing patch 041, but that broke some of the flags used in other patches. Finally, I've found a solution here: https://bugs.lede-project.org/index.php?do=details&task_id=832
(and other places like https://github.com/buildroot/buildroot/blob/master/package/gcc/6.3.0/942-ubsan-fix-check-empty-string.patch)
PS.: @gwlim, I don't think you need to add this to your repo, as hopefully it'll be merged upstream soon enough. I'm just leaving it here for those having trouble.
1 Like
did someone tested this builds with pppoe ? if yes what are the improvements ?
thanks