Any news about hardware offloading support on WHW01

Speeds on this router don't go above 200Mbit when NAT is used.

Linksys WHW01
ARMv7 Processor rev 5 (v7l)

Hardware offloading states
Requires hardware NAT support. Implemented at least for mt7621

Any ideas if this will work on that hardware. Real speeds should be around 500-600Mbits.

root@Master:~# uci show | grep 'offloading'
firewall.@defaults[0].flow_offloading='1'
firewall.@defaults[0].flow_offloading_hw='1'
root@Master:~# cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 67.03
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 1
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 67.03
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 2
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 67.03
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 3
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 67.03
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

Hardware	: Generic DT based system
Revision	: 0000
Serial		: 0000000000000000
OpenWrt 23.05.0 r23497-6637af95aa / LuCI openwrt-23.05 branch git-23.292.78378-27fb6e5

AFAIK it's only working for MT.

Sad, but then it gives OpenWRT a huge drawback on non-MT. Isn't hw offloading like core in all 1Gbit+ routers? Or just not to use NAT on these routers? Or use IPv6 only?
What's the solution?

Routers that are x86-based and some higher-performing ARM-based ones (like Raspberry Pi 4) can route at gigabit speeds using only their (relatively high) CPU processing speed, without NAT-specific hardware. This is useful for people that use traffic shaping, as that is incompatible with hardware offload.

1 Like

go back to stock, or get a MT based device.

No plans to support Qualcomm ?

not 100% sure, but I believe it's a hw support/functionality issue, and Qualcomm haven't bothered (on purpose, perhaps) adding it to their public code.

Qualcomm IPQ4018 doesn't have NSS cores so I don't think HW NAT will ever be supported. There are community builds (not mainline OpenWrt) for IPQ806x and IPQ807x with NSS support but there is nothing for IPQ4018 and I don't think there ever will be.

When I decide to purchase a new device with intention of running OpenWrt on it, I research what the performance is on this forum and elsewhere beforehand and if it works for the use case, great!

This device can be a great AP with VLAN support and if you decide to use it that way it will work fine. Otherwise, if it doesn't perform as you expect, go back to stock.

Generally: OpenWrt is built in a completely different way from stock firmware. Stock firmware is developed in the following way:

  • SoC vendor starts developing the SoC
  • during development, at some (early) point they select a linux kernel version to use as a base - let's say they use kernel 3.10
  • then they write proprietary drivers on top of that kernel version - in a way not compatible with upstream kernel development process - and call it "Base support package"
  • they never update the kernel version for the entire support period of the SoC (let's say 5 years), and after the support period ends, no further fixes are supplied
  • Device manufacturer uses the BSP and slaps their GUI on top with the desired features
  • if SoC vendor sends a BSP update to the device manufacturer (with for example security fixes), the device manufacturer can then publish an updated firmware - but this is still using that old kernel.

OpenWrt is developed in a completely different way:

  • starts with modern upstream linux kernel with baked-in open source support for the SoC
  • adds some patches and even newer open source drivers on top of the modern kernel to have even better support for the hardware attached to the SoC
  • has it's own build tools to prepare the firmware for specific devices
  • has a list of Device Tree files and build scripts to describe the exact hardware it is going to be running on

You shouldn't expect the same performance as these two ways of development are almost completely incompatible with one another, and the only way to achieve better performance is to persuade SoC vendors to send their hardware acceleration code to the upstream Linux kernel.

2 Likes