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
Would saving/exporting/backup current settings and reloading them in 4.14 work?
Yes. So far there is no change in the actual settings. The change it is only about flash space allocation.
(But it is possible that at some point there will be a change in the hardware switch driver logic, and that would break the switch settings, preventing restoring them.)
ipq806x target (including R7800) in 18.06 was bumped into 4.14 a few minutes ago.
This means that the "sysupgrade break" and TFTP usage will move into between
- (17.01, old 18.06 builds, old master builds)
and - (new master builds, new 18.06 builds).
Thus my next 18.06 build will be with kernel 4.14 and the new kernel partition size.
There will be no new 17.01 builds unless some major fixes/changes happen there. But I expect 17.01 sources to be rather dormant.
EDIT:
owrt1806-r6984-fa0275bd90-20180524-TFTP-flash-kernel-4.14
first 18.06 build with kernel 4.14 (and flow offloading possibility)
1 Like
is reverting to stock still as easy as doing a tftp flash or should we manage the kernel partition separately?
thanks 
Should be.
TFTP flash in handled by u-boot, which is not touched by Openwrt, so the TFTP recovery flash will be able to flash quite normally either a Netgear OEM image or an Openwrt factory image.
Can anyone comment on the state of kernel 4.14 with the R7800 before I upgrade? It's been running well on WRT3200ACM builds, but over at DD-WRT, Kong builds avoid this kernel and have backported FastPath/SFE to 3.x. Has 4.14 made good progress? Looking forward to FastPath/SFE support at the very least, it's a huge performance improvement. Closer to stock firmware (which does hardware NAT).
Devs did not select SFE/fastpath, but chose kernel built-in flow offloading instead, so no point in looking for SFE/fastpath specifically.
But hard to understand why somebody has stayed with ancient 3.x, except for lack for resources to do a bump to 4.x. kernel 4 was released years ago.
For generic R7800 kernel 4.14 discussion, the r7800 exploration thread is a better place than this buildspecific thread.