freenode
Distributions & Plumbing

IPQ5018 NSS offload works on upstream stmmac at Linux 6.18

A public fork accelerates routed NAT on the GL.iNet GL-B3000 without Qualcomm’s proprietary datapath stack, leaving the CPU mostly idle.

Hardware NAT acceleration on Qualcomm’s IPQ5018 is now demonstrated with Linux 6.18 and the upstream Synopsys stmmac ethernet driver, without the usual qca-nss-dp or qca-ssdk layers. The work, posted by kuncy7, has been running for a week on a GL.iNet GL-B3000 and keeps the host CPU above 90% idle while routing NAT traffic.

The approach sits on Julius Bairaktaris’s broader NSS-on-mainline effort. A small glue module hands selected GMAC controllers to the NSS firmware at runtime: the firmware owns DMA and transmit, while phylink, MDIO, and the netdev remain under the kernel so link and PHY management stay ordinary. Takeover is optional via a debugfs mask; if it fails, the port simply keeps the host datapath, so a broken experiment still leaves a reachable router.

This is a second working IPQ5018 path, not the first. ADCDS earlier brought up NSS on a Xiaomi AX3000T using qca-nss-dp, an Airoha switch, and 6.12. The new tree pairs upstream stmmac on 6.18 with a QCA8337 switch instead. Together the two cover most IPQ5018 board designs in some known-working form. Boards such as the Linksys MR5500 (same SoC and switch pairing) need only device-tree and port-map differences.

Mainline OpenWrt will not absorb the full stack. Acceleration still depends on a proprietary firmware blob and out-of-tree patches, so the practical home remains community forks. Isolated pieces that stand alone, including a CMN PLL clock fix and the stmmac claim API, are candidates to go upstream on their own merits. Wi-Fi continues on the host path; NSS here targets the wired forwarding engine only.