In that case, will the kernel 4.14 support be dropped for these targets (D7800, R7500, R7500v2 and R7800) ? Do you see an official workaround coming ?
Edit: by "official workaround", I meant a communication/documentation approved by the devs
Please take the kernel 4.14 into the "R7800 exploration" thread, where it belongs. (and is already being discussed: Netgear R7800 exploration (IPQ8065, QCA9984) - #1063 by bouwew )
This thread is about my current build, not about generic development for the whole ipq806x target.
Sorry about that
master-r7016-52809db544-20180522-TFTP-flash-kernel-4.14
Master has now a larger kernel partition, so that kernel 4.14 and flow offloading is possible. TFTP recovery flash is required to install master builds r7000+ (or to revert from new master back to older master or 18.06 or 17.01)
Explanations in
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6
I have not tested flow offloading myself, yet, but the modules should be built-in:
OpenWrt SNAPSHOT, r7016-52809db544
-----------------------------------------------------
root@OpenWrt:~# uname -a
Linux OpenWrt 4.14.42 #0 SMP Tue May 22 20:00:31 2018 armv7l GNU/Linux
root@OpenWrt:~# opkg list-installed | grep off
kmod-ipt-offload - 4.14.42-1
2 Likes
Enabling flowoffloading works via uci set firewall.@defaults[0].flow_offloading=1; uci commit firewall (it's disabled by default).
1 Like
how to check if the flow offloading has been enabled or not?
flow offloading work with sqm scripts?
Based on the comments from nbd, the software offloading does not bypass the qdiscs, only iptables rules, so SQM might work, I think.
2 Likes
My understanding is that both SQM and offloading are mutually exclusive. The main purpose for offloading is that some packets are going to avoid the kernel netfilter and are offloaded directly to the wan device. SQM sets up a special device and qeues for traffic classification and priorization. Probably @moeller0 can make a more technical and better explanation.
So it should work!. i was wrong then.
So traffic between the wan interface and SQM should be offloaded
Yes, by hnyman's and nbd's insights. I thought the offloading was similar to the shorcut-fe engine. In that case both shortcut-fe and SQM were mutually exclusive.
Enabling SQM and (software-) flowoffloading won't break anything (hardware offloading might be more intrusive, but so far that's only available for mt762x, not ipq806x or ar71xx), but with SQM enabled, there won't be any flows that could be offloaded (as the kernel needs fine grained control over each frame). So yes, you can enable both, but flowoffloading loses and essentially disables itself if SQM is active; the net effect might be slightly worse, as the flowoffloading algorithm will continue to check each package if it can offload it, only to realize that it can't.
3 Likes
Thanks for clarification. Looks like I interpreted nbd's comment too optimistically.
So it's not possible to enable in the UI yet? Thanks for the commands, will try this out. Hoping someone can chime in soon on the performance gains. On DD-WRT enabling SFE (similar feature I think) performance jumps to 300Mbits to 900Mbits on the R7000 and R7800.
Isn't DD-WRT using the OpenWrt kernel now? Albeit sometimes with different patches and/or proprietary bits, depending on the platform. I bet the SFE is either the same as what's in OpenWrt or it's Qualcomm Fast Path (which has patches available for OpenWrt, but was turned down in favor of the current flow offloading functionality).
SFE = Shortcut Forwarding Engine = Qualcomm fastpath
See a clean patch about that https://github.com/lede-project/source/pull/1269
But as core devs selected the native kernel based flow offloading, the fastpath/SFE will likely never enter Openwrt mainstream source code.
there is a man who wrote luci app to control flowoffloading
https://github.com/coolsnowwolf/lede/blob/master/package/lean/luci-app-flowoffload/Makefile
1 Like
Awesome @hnyman!
So, just for the record, if I'd want to flash this new master with 4.14 kernel, I can not upgrade the current master I've got in there at the moment? In other words, I must use the TFTP recovery flash to install this master build with 4.14 kernel?
I assume that any subsequent, newer master builds with kernel 4.14 (and higher) can then be easily upgraded again like before?
I'm gonna hold on to doing anything fancy at the moment to my network at the moment, my wife is finishing a study the following weeks. I don't want to break anything before that's done 
To my knowledge, yes, you really need to use TFTP recovery mode.
The sysupgrade is done in two phases in R7800, kernel is written separately and rootfs part separately. As the flash area reserved for kernel now grows with the new 4.14 firmware, the rootfs part would overwrite kernel if it is written to the old location (by the old version). Thus you need to flash with the united factory version that gets written as one continuous block.
Yes, sysupgrade should work normally in future, as long as you only use it for new 4.14 images.
1 Like