盘点高通网络处理器中的硬件加速技术，NPU、HNAT、ESS、NSS、PPE、SFE、ECM、UDP

啵妞妞

本文经过原作者授权 首发于CHH论坛    未经作者授权 禁止转发  

从事网络产品开发的朋友大概率都会面临设备转发性能优化的问题，设备的吞吐量低、性能不稳定、延迟/抖动大、CPU利用率高等都是咱们开发过程中遇到的常见问题。在网络

设备转发方面其实有很多软硬件加速技术，高通在这方面推出的技术概念多、方案复杂，常常把大家搞得晕头转向的，笔者今天就给大家好好盘一盘这方面的知识点，帮助大家理

清这些加速技术之间的关系，也同时介绍NPU、HNAT、ESS、NSS、PPE、SFE、ECM、UDP这些缩写到底指的是啥。


高通网络芯片发展史如果想要彻底搞明白高通的各代网络芯片产品的技术特点，笔者建议大家抽点时间了解一下高通的发展史，或者叫做“收购史”，网上介绍这部分的知识比较

多，这里就不重复介绍了，推荐看看知乎上的这篇文章。






来源：https://zhuanlan.zhihu.com/p/783650641



在网络芯片产品方面，我们重点关注对Atheros和Ubicom的收购。在2010年高通收购Atheros，使其具备了在Wi-Fi芯片领域跟当时的老大（博通）具备了抗衡的能
力；而Ubicom以做网络处理器（NPU）闻名，是高速网络通信SoC标准IP核配置之一，并且与Atheros基本上算是共生关系，所以在Atheros被高通收购不久的2012
年，高通低调的将Ubicom也收入囊中，从而实现了Wi-Fi芯片方案的完整的生态。
网络加速思路
回到网络加速这个话题，对于报文转发性能的话题，无非就两个思路：

• 让报文转发的路径尽可能短，在网络设备内部而言，就是减少函数调用，减少报文在网络协议栈中的流转的路径长度。
• 尽力少让CPU参与，也就是Offloading，使用专用硬件来处理报文转发的工作，让绝大多数情况下CPU不参与、极少情况下CPU参与极少的配置流表的工作。
  

基于以上两点，我们就来看看高通到底使用了哪些网络加速的技术。
HNAT
HNAT是Hardware NAT的简称，也就是通过专用的硬件来实现NAT的功能。NAT技术本身是为了解决内外网IP地址转换的问题（三层转发/bridge转发），其原理就
是查表，只是在Linux网络协议栈中，这部分工作都是软件实现的，需要消耗大量的CPU计算资源。可是在嵌入式系统中，CPU的性能有限，并且很多时候CPU还需要
承担很多非转发业务的工作，这样就出现了CPU资源的竞争，这就导致了报文转发的任务很可能无法立即处理、需要排队的情况，这也是导致网络转发性能低、延迟/
抖动大的主要原因。
为了解决这个问题，早期的芯片方案中都是通过实现一个专属的HNAT硬件模块来解决报文匹配和转发的问题，高通的芯片方案中使用该技术的典型产品就是IPQ40XX
Wi-Fi 5系列产品，下面是原理框图。






来源：https://github.com/Deoptim/ather ... Q4019-datasheet.pdf




不过，在高通的一些文档中，会把负责以太报文转发的这个子系统称之为以太子系统ESS (Ethernet Sub-System)，因为那个时候的ESS功能相对简单，所以，你可以
简单理解为ESS就是指的HNAT。

注意，HNAT也有资源限制，主要是在表项数量方面。
NSS&ECM
前面提到，高通会有一段短暂的时间把负责网络转发硬件加速的模块称之为ESS (Ethernet Sub-System)，但是随着后面大家意识到大多数情况下这个硬件加速功能需
要处理的是Ethernet和WLAN之间的报文收发，所以称之为以太子系统也不大合适了，后面就正式改为网络子系统NSS (Network Sub-System)。
从IPQ806X系列开始，就开始使用NSS的概念，一直到现在。
引入NSS概念之后的流量加速模型可以如下图所示：

来源：https://netdevconf.info/0.1/docs ... acceleration_v3.pdf

在此模型下，常规流量仍然需要转发到CPU处理（HLOS，High Level Operating System，上层操作系统），主要任务是做规则匹配，如果确认为需要加速到流量，
则会下发一条流表配置到NSS，这样对应flow到后续报文都不用再上CPU处理，而是直接通过NSS加速转发，好处是不用CPU参与、报文转发路径短，所以可以获得更
好的吞吐性能和时延表现。
在NSS加速模型中，需要一个负责管理网络连接加速规则的软件模块，在高通的技术栈中称之为ECM (Enhanced Connection Manager)，如下图右上角的部分。ECM的
主要作用是加速和连接管理，一方面，它需要维护整个系统中的网络连接信息；另一方面，它需要根据配置的规则分析建立的网络连接中哪些走硬件加速、哪些走软件
转发。




来源：https://netdevconf.info/0.1/docs ... acceleration_v3.pdf



NSS是流量加速硬件，ECM是流量加速管理软件，由ECM来配置和管理如何使用NSS的规则。
NSS的技术迭代
我们可以理解为NSS只是集成在网络处理器中的一组负责网络加速的硬件模块，但是内部的功能规划方面，高通一直在进行技术迭代。
NSS最早出现在高通Wi-Fi 5时代推出的IPQ806X CPE/Gateway方案产品上，集成了双核Ubi32的NPU，最高主频可以达到800MHz，原理框图如下。


可以看出，这时的NSS由负责网络处理的双核Ubi32 NPU和加密引擎两部分组成。我们把这里的负责网络加速、可以编程的独立MCU称之为NPU（Network
Processing Unit），它的特点是硬件Offloading、可以定制软件，如果你有技术实力，完全可以自己改写里面的程序，烧录自己的NPU/NSS固件。
然后到了Wi-Fi 6时代，旗舰方案IPQ807X方案做了进一步增强，它的NSS在上一代IPQ806X的基础上增加了一个性能更强的高处理引擎PPE (Packet Processor
Engine)，负责确定的报文转发、流量分类和QoS的工作。另外，在继续保留双核Ubi32 NPU的情况下，将主频提高到了最高1.7GHz，报文处理能力更强了。


那么这个时代的NPU（Ubi32 core）和新增的PPE又有什么区别呢？
第一是两者在报文转发路径中的层级不同，PPE更接近网络接口层，报文会首先经过PPE，也就是说，如果PPE匹配到报文可以直接转发，它是不会上送到NPU的；如果PPE没有匹配上转发规则，则下一步上将报文上送给NPU处理；如果NPU还是处理不了，则交给软件的ECM模块处理。
第二是两者的性能差异极大，比如IPQ807X的转发性能是20Mpps，也就是每秒钟可以转发2000万个包，而NPU的性能是每个核2.2Mpps，相当于性能差距接近10倍。
第三是两者的灵活性不同，PPE的程序逻辑是固化的，没有提供可编程能力；而NPU是可以编程的，里面跑了一个12线程的MCU的实时操作系统，你可以修改所谓的NSS固件代码。
我们知道高通的Wi-Fi 6平台方案除了旗舰的IPQ807X/IPQ817X之外，还有IPQ60XX和IPQ50XX两个系列，这两个系列你可以理解为基于IPQ807X向下裁剪的版本。

IPQ60XX裁剪的不算太狠，只是将NPU改为了单核Ubi32 core@1.5GHz，报文处理性能仍然是2.2Mbps；同时保留了PPE，不过性能降到了14Mpps。比如，下图是
IPQ6000的原理框图。



到了IPQ50XX就裁剪的比较狠了，一方面是直接去掉了PPE，同时将NPU改为了单核Ubi32@1.0GHz，虽然说官方并没有提供pps的转发性能数据，但是估计也好不到
哪里去。比如，下图所示为IPQ5018的原理框图。



高通从Wi-Fi 7这一代开始取消了NPU，只保留了PPE硬件加速模块，当然该模块的性能应该说是更强了才对。比如下面这是最新的IPQ54x4硬件平台的原理框图，同
样也只有PPE硬件加速模块，不再提供NPU的可编程能力了。



为什么会取消NPU呢？笔者个人见解，主要原因是不再需要可编程的NPU了，高通的硬件加速技术已经非常成熟，能够满足绝大多数使用场景，所以可以将程序固化


了，不再提供可编程能力。试问一下各位网友，有几个人改过NSS的固件代码呢？还有，既然PPE已经足够使用，也可能是出于成本的考虑，没必要在NSS中保留两个


硬件加速模块。


高通从Wi-Fi 5到现在的Wi-Fi 7一路走来对NPU的迭代就讲完了，笔者整理了一张脑图，帮助大家对照总结。






SFE&UDP



高通不仅仅是在网络加速硬件方面做了优化，即使软件加速方面也有许多改进。比如，在ECM框架之下，开发了一套软件加速方案SFE（Shortcut Forwarding


Engine），它通过在Linux标准网络协议栈中增加SFE的钩子函数，借助ECM维护的连接数据库来快速转发，从而减少Linux网络协议栈中的调用路径。






从Wi-Fi 7开始，高通统一了所有的软硬件加速的技术栈，推出了统一数据路径UDP（Unified Data Path），通过这个提供了统一的数据转发模型，以便于我们在实际


项目中做出合理的功能规划，也能无缝使用高通的各种网络加速技术，如下图所示。









总结

本文我们盘点了高通在网络加速方面的软硬件优化技术，虽然没有深入技术细节，但是足以帮助大家了解个大概。如果我们拿着这些再来对比同行，不知道大家有何感

想，就笔者自身经历而言，学技术还是推荐大家首选高通方案。但是，可能现实条件不允许，目前OpenWrt官网已经支持到了IPQ40XX、IPQ806x和IPQ807X方案，

如果大家有条件的可以学习一下。高通在OpenWrt上支持的单板丰富度上确实跟联发科的方案差很多，也希望高通从下一代产品开始能够让大家更容易获取到新硬件

的开源代码。

啵妞妞

虽然是帮站长转发  但是我也要替站长更正一下 里头有一些参数错误   高通在WiFi6的主打芯片  Ipq807x系列芯片的ppe 小包转发率  已经是37.5mpps
已经跟站长沟通  没有在文章中纠错  抱歉

啵妞妞

顺便补充一些基础知识  
封包处理的手段
关于npu

Npu属于微码引擎处理器内核  可编程 可完成多种报文处理任务  效能逊于ppe  功能大于ppe

关于ppe
ppe属于asic硬件电路  完成专用定制报文转发任务   效能最高
功能单一  优点省电 延迟低  吞吐率 报文转发效率高

啵妞妞

个人看法 高通这种基于流的报文识别加速技术  是目前比较完美的方案   
Ppe能处理的就走ppe加速   ppe加速不了的就丢给npu  Npu加速不了的就交给sfe 和udp    就是一个目的 让报文尽量通过硬件加速手段完成转发 避免走传统Linux网络堆栈  减少中断占用 排队丢包延迟

hp5152688

好文，但各种突兀的换行很影响阅读的连贯性

goat

好文章。
但是个人感觉公版加速单元这玩意儿就是通用单元性能不够，四不像的加速单元来凑。多多少少这个不支持，那个不开放。外加这种完全没开源的饼看着美好实际出漏洞/bug芯片厂先花不知道多久，oem在拖十天半个月，等用户部署搞不好还是需要等重启的冷补丁。最后还很可能限平台，博通的toe因为怕漏洞还是啥来着linux就没正式支持过。
真有用是卖方案的知道自己要什么只有直接定制，定向优化，然后服务到期...再掏钱吧

啵妞妞

hp5152688 发表于 2025-10-19 00:49
好文，但各种突兀的换行很影响阅读的连贯性

直接转过来 有各种乱码  没办法 凑合着看吧  Pc版面有点乱  用手机版会好很多

zvcs

所以高通的开发板或者是适配本来就很复不知道mtk那边是不是有类似的东西

bucom

哪种开启硬件加速，不影响流量统计和QOS？

Juzi丶

专有加速单元都是垃圾，只会徒增bug

hc313

zvcs 发表于 2025-10-19 10:01
所以高通的开发板或者是适配本来就很复不知道mtk那边是不是有类似的东西

mtk收购ralink后无线发力，转发上还是靠hwnat

hc313

bucom 发表于 2025-10-19 18:32
哪种开启硬件加速，不影响流量统计和QOS？

现在较新的芯片的都带流量接口了，可以统计流量。

qin11745

文件介绍不错，感谢分享

Emmerich

啵妞妞 发表于 2025-10-18 20:22
虽然是帮站长转发  但是我也要替站长更正一下 里头有一些参数错误   高通在WiFi6的主打芯片  Ipq807x系列芯 ...

这部分文档可以分享下吗，想了解下NSS/PPE支持多少条流加速

dcl2009

加速一条龙，超限一条虫，说的就是这个。对应x86就是力大砖飞，啥加速都不需要，硬顶上去。

啵妞妞

Emmerich 发表于 2025-10-22 16:49
这部分文档可以分享下吗，想了解下NSS/PPE支持多少条流加速

我帮你向作者问了一下 因为NDA的原因  目前尚无法分享   我可以向你偷偷透露一下是64k

啵妞妞

Emmerich 发表于 2025-10-22 16:49
这部分文档可以分享下吗，想了解下NSS/PPE支持多少条流加速

关于加速条目数无需担心  家用宽带线路上在在局端就已经给你限定死了  特别是目前运营商在全面封杀 p2p和pcdn  在上游局端线路就已经做了各种条目限制  

huangya

ipq40xx中hwnat有人跑通过吗？不管是开源代码，还是高通的sdk似乎都没有使用过它，或者默认enable 它？楼主有试过吗？

Emmerich

啵妞妞 发表于 2025-10-22 18:14
我帮你向作者问了一下 因为NDA的原因  目前尚无法分享   我可以向你偷偷透露一下是64k ...

好奇NSS奇奇怪怪的小知识很久了，感谢解答~

啵妞妞

huangya 发表于 2025-10-22 19:11
ipq40xx中hwnat有人跑通过吗？不管是开源代码，还是高通的sdk似乎都没有使用过它，或者默认enable 它？楼主 ...

40系列确实太小众了 只在一些单ap方案上见过  而且这个是属于高通初代的hnat 是跟交换芯片整合在一起的 其他的确实知道的不多