Hi!, i've also reached to a moment that i have to invest a lot of time to read and improve my knowledge of linux device drivers and kernel. With two kids and a job it's quite difficult 
With the new flow-offload feature and the DSA architecture ... i don't know if this hack will be worth ... but just for fun 
well actually not... having hardware offload THAT SUPPORT QOS is really good...
flow offload doesn't support qos traffic...
For an embedded system, every little bit of CPU resources counts. 
For me, I’m more looking toward unlocking the NSS cores to speed up crypto functions. With SFE already working well for me on the 4.4 kernel, NAT thruput is not a problem.
Problem is SFE is mutually exclusive with QOS.
NSS cores support hardware accelerated qdisc, which means if you can do hardware offload you might be able to do hardware QOS as well.
IMHO, QoS is only really useful for relatively low bandwidth uplink and high utilisation when the uplink is always maxed out. Downlink usually can’t be effectively throttled, not with consumer grade equipment anyway.
It all depends - if you're using VOIP and also doing large downloads or uploads it's definitely useful to prioritise more realtime traffic, even on a connection like mine (384Mbps down, 22Mbps up)
QoS and more specifically, SQM targets the bufferbloat problem. I agree with @philjohn, offload and QoS are mutually exclusive, because both address different problems. The nss cores can accelerate IPv4, IPv6, NAT, PPPoE, L2TP, VLAN and Qdisc.
Any updates on this?
Question: Does network forward to NSS cores or is this also a problem because of the crypto?
-deleted- -:10char
I'm quite amazed why so many do not pay attention to this thread as the NSS cores are insanely critical for the IPQ806x routers. NSS core do all the heavy networking including the same thing IRQBalance works + you have 2 cores that do completely nothing as all the load is on NSS. I'm currently on the ZyXEL NBG6817 / Armor Z2 (AC2600) which does have the same specs as the R7800 But i'm too scared to use your firmware as i don't have the equipment to debrick if required.
I'm currently original firmware because of streamboost + nss cores, since openwrt firmware can't handle 400/40 mbit connection over wan not even with the "flow offloading" and the "hardware offloading".
What do you suggest + have any ideas what i can do to help you out with the nss issues. Is it even possible for me to use your build?
It is very hard to really brick the nbg6817 beyond the scope its internal u-boot push-button tftp client can recover, its spi-nor flash (containing bootloader, crucial calibration data, NSS firmware, etc) isn't touched by flashing it (except for toggling the bootflag, using a dedicated mtd).
Okay.
The reason i'm scared is because someone mentioned in this thread that he got stuck in a bootloop and in the R7800 exploration thread someone else couldn't flash to original firmware anymore. Hence why i'm scared.
Plus he build it on top of the R7800 not the Zyxel.
Also i think the kernel of current release has a better network patch then his current fork.
What do you suggest as the NSS cores are actually really critical after 2 months of testing on openwrt + testing on the 18.06 release + many weeks of testing on original firmware.
Also to mention the Zyxel uses an outdated OpenWRT firmware:
I just recommend going with recent master snapshots for installing OpenWrt from the OEM firmware or tftp recovery, as that provides proper factory images that are safer to use than the previous approach of overwriting the partitions manually.
But then i will fall back to the same problem of not reaching the 400/40mbit over wan. As 18.06/.1 can't handle it not even with flow offload. Hence the reason why i used tftp recovery to get back to oem firmware.
Hence why i'm more interested in @quarky his patch.
Problem is that he build it on top of R7800 which i presume will not work on my zyxel?
I recommend to use the OpenWrt nbg6817 factory images, which have been recently introduced in master, for the initial OpenWrt installation from the ZyXEL OEM firmware or for the bootloader tftp recovery - what you do from there via sysupgrade is another topic (you can downgrade/ upgrade with the usual caveats; just don't go below 17.01.5).
Obviously you can not use a binary r7800 firmware on the nbg6817.
How do i do this exactly? Get the this image: http://downloads.openwrt.org/releases/18.06.1/targets/ipq806x/generic/openwrt-18.06.1-ipq806x-zyxel_nbg6817-squashfs-sysupgrade.bin
Then install that through the oem cpanel or how do you mean exactly with "initial OpenWrt installation from the ZyXEL OEM firmware"
Got error while upgrading from oem luci panel:
Firmware upgrade error...
The flash image upload failed. The error messages are as follows:
That is not the latest firmware, so can not update it.
I explicitly mentioned master/ factory images, as in e.g. https://downloads.lede-project.org/snapshots/targets/ipq806x/generic/openwrt-ipq806x-zyxel_nbg6817-squashfs-factory.bin; 18.06.x doesn't provide them yet. If you build from current master yourself, you'll get factory images as well. Please consult the wiki for details.
Edit: just to clarify, and without going even more off topic, the factory images are always used when the OEM firmware is in charge (flashing from the running ZyXEL firmware or using the ZyXEL bootloader's tftp recovery), the sysupgrade images are used for up- and downgrading OpenWrt; only >=18.06.x is full featured for the nbg6817 (in terms of dual-boot and wlan support), only recent master provides factory images for the nbg6817 (which are safer to use than kernel/ rootfs images).
@quarky
I got this for you if it helps?
kmod-qca-mcs - 3.4.103-1
kmod-qca-nss-cfi - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-crypto - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv-ipsecmgr - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv-profile - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv-qdisc - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv-tun6rd - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-drv-tunipip6 - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-ecm - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-gmac - 3.4.103+gf7b97d9-dirty-1
kmod-qca-nss-macsec - 3.4.103+gf7b97d9-dirty-1
kmod-qca-ssdk-nohnat - 3.4.103+gf7b97d9-dirty-1
kmod-qca-wifi-10.4-akronite-perf - 3.4.103-1
kmod-sched - 3.4.103-1
kmod-sched-connmark - 3.4.103-1
kmod-sched-core - 3.4.103-1
kmod-scsi-core - 3.4.103-1