Qualcomm Fast Path For LEDE

That would be great.

Apart from the basic routing, WiFi and firewall functionality, I use cron, dropbear, sqm and ddns.
No odhcpd, vsftpd, etherwake, xl2tpd, miniupnpd, igmpproxy required.
I'm note sure if more can be disabled without crippling it too much. E.g. I don't need USB access, telnet (probably a requirement for recovery purposes) or NTP server (sysntpd probably acts as both server and client). I guess I could even live without a web interface after configuring it once.

1 Like

Thanks, this build worked fine.

@gwlim how do you feel about porting this to old BMIPS4350 bcm63xx devices? Dou you think there will be some noticeable performance improvements? I'm interested specifically into Netgear DGND3700v1 for which lede support is quite good. I actually have gigabit fibre wan nut I can't get more than ~280 MB/s wan-to-lan (it's a pppoe over vlan wan, ethernet, no dsl) with OpenWRT/LEDE or stock firmware.

i only tested my two with iperf before / after and both were improved but since i was testing from within a vm box i thought it's not proper to share the results since they were not direct links from device<->device. any other tests i would gladly run/try (like Kpps) if you shared how but i just understand this improves the local link and that's obvious to me from your first post and the iperf tests i ran :slight_smile:

also, i thank you again for still working on this for everyone :blue_heart:

In what scenario do you need this, have you worked with openvswitch ? it works better than linux bridge, at least on high end machines

does this means that x86 could benefit from it ?
I have some 1ghz low power semprons that can do ~850 mb/s on nat but using pppoe on wan they can only do ~650 mb/s

which is better for wireless, ct (candellatech) ath10k-ct or standard ath10?

Yea exactly high end machines.
The thing about optimizing for low end machines when you put it in high end machines it will fly.
But the other way round is not always true

I haven't tested personally, but I think standard is more updated at this point. ct based on an old version with some backports. I know r00t switched to standard for his custom C7 build, probably for that reason.

https://wiki.openwrt.org/doc/howto/benchmark.nat
You won't know until you test.
Above test takes only 5 minute you don't have to do the WAN part 10.1.1.2 <-> 192.168.1.X
You just have to do WiFi to Lan 192.168.1.123 <-> 192.168.1.124

Thanks!

Would it be possible for you to include this into the master tree?

Cheers.

I think @greearb has an NDA and so has access that others do not.

I tried to build with FastPath for my router (Buffalo WZR-900DHP), and succeeded.

The summery of specifications of this router are as follows:
SoC: BCM47081A0 (ARM, bcm53xx)
RAM: 256MB
Flash: 128MB
WAN/LAN: 1Gbps

Simply, I tested by transferring file (4GB) from wan to lan with smb protocol.
FastPath off: 288Mbps (average)
FastPath on: 380Mbps (average)

The above was just a quick report.

1043ndV2(QCA9558)@1080CPU/920MemMgz tested. FullDuplex ~1400Mb(~950M in ~450 out) sirq 95%

I redo all my configs and didn't work, my lan interface continue up and down constantly when I connect to wan port,
for internet( 1GB fiber pppoe) I neeed to create vlan10( eth0.10) with cpu and wan port tagged, and assing the ppp0 to eth0.10.
This works with another builds openwrt and dd-wrt, but it's failing with yours do you think it might be related to your changes or this is a problem related to pppd in LEDE ?

Wow i have WZR-1750DHPD i will try to build for that.

@gwlim does the build for 1043nd v2 also applies for v4 or do we need another version to be compiled? I have no available resources atm so I'd be so grateful If you could make a build for that also. Anyway, I just want to say a huge THANK YOU for the impressive work you already have done.!

I think it might be due to the hardware nat kernel support patch, it is still inside I will move that somewhere else and rebuild

OK Thank you !!

I did some research and found out the following:

  1. The upstream code repo by qualcomm is https://source.codeaurora.org/quic/qsdk/oss/lklm/shortcut-fe/, and the upstream OpenWRT/LEDE feeds is https://source.codeaurora.org/quic/qsdk/oss/system/feeds/shortcut-fe/.

  2. The kernel patch by qualcomm is https://source.codeaurora.org/quic/qsdk/oss/lklm/shortcut-fe/tree/patches?h=banana, looks minor, but for kernel 3.x only. Rework the patches for kernel 4.4(which was already done by gwlim), it's possible to build SFE as an optional package, and make it into OpenWRT/LEDE upstream.

  3. ChromeOS team maintains a fork of SFE for kernel 3.18 https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/net/ethernet/qualcomm/sfe/, but the code is gone in chrome-4.4 branch https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/net/ethernet/qualcomm/

  4. Searching sfe in chrome os gerrit https://chromium-review.googlesource.com/q/sfe gives some commit/submit history.

  5. It looks like gwlim's patches are based on ChromeOS team's fork.

1 Like

Here where all patches should come from https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/log/net/?h=eggplant
But there are too many changes to track which are connected to shortcut-fe
I guess the initial commit is https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit?h=eggplant&id=bc967779e3f6cf49bef2fc6b79c9dfdf9fa8389a

@gwlim could you please separate qca-ssdk patches from shortcut-fe so this packages can be applied independently?

Edit: the 2nd commit is https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/net/netfilter/nf_conntrack_proto_tcp.c?h=eggplant&id=0a981d12fc2bfe71d19caf2ddb462c714a0d2e43

edit2: I guess that's all that is needed, let's check...

edit3: unfortunately it doesn't compile in k4.9, the code in sfe package has to be adjusted :confused: as some structures has changed since k4.4

1 Like