终端路由器芯片加速学习机制详解——内核和芯片是怎么配合转发的

在前两篇文章中我们多次提到加速学习这个机制——硬件加速不是一上来就生效的需要先经过内核学习几个报文芯片才能接管转发。本文详细拆解这个过程讲清楚加速学习的触发、学习内容、表项管理和老化机制。1. 为什么需要加速学习在 终端路由器中芯片硬件加速可以让绝大部分数据流量在芯片内部完成转发不经过 CPU从而大幅提升转发性能、降低 CPU 负载。但问题是芯片不知道每条数据流该怎么处理。报文进来之后该走 bridge 还是 route从哪个口出去需不需要打 mark需不需要做 NAT这些决策逻辑都在 Linux 内核里。芯片本身不具备这些复杂的决策能力。所以就有了加速学习机制让前几个报文走一遍 Linux 内核的完整处理流程芯片 SDK 在旁边观察并记录处理结果学习完成后后续同一条流的报文就可以直接在芯片里按照学到的方式转发。[新数据流的前几个包] │ ▼ Linux 内核完整处理bridge/route/hook/NAT... │ ▲ │ │ SDK 观察并记录处理结果 ▼ │ 转发出去 写入芯片加速表 [后续包] │ ▼ 芯片查加速表 → 直接按学到的方式转发不经过内核2. 加速学习的触发时机一个常见的误解是前几个报文走内核是因为芯片需要多个报文才能学完。其实不是。从技术上讲一个报文就足以学到所有的加速信息。那为什么还要让前几个包走内核呢包速率阈值pps threshold答案是芯片设置了一个包速率阈值——一条数据流的报文速率必须达到每秒多少个包pps的标准才会被纳入加速。为什么这样设计加速表的容量是有限的常见 4K-16K 条。如果每条流不管流量大小都立即进加速表会导致• 大量低流量的连接比如偶尔一个 DNS 查询、一个 NTP 请求占满加速表• 真正需要加速的高速流量视频、下载、游戏反而没有资源可用所以芯片的策略是新数据流 → 前几个包走内核 → SDK 统计包速率 │ ┌───────┴───────┐ ▼ ▼ 达到阈值 未达到阈值 → 创建加速表项 → 继续走内核 → 后续包走芯片 (低流量不值得占用加速表)这是一个很巧妙的资源管理策略• 高速流量视频、游戏、下载——包率高迅速达到阈值进入加速硬件转发• 低速流量DNS、NTP、偶尔的 HTTP 请求——包率低不进加速走内核软件转发就行• 这样加速表的容量就能留给真正需要的高速流量不会被低流量连接占满学习本身是即时的需要强调的是学习从第一个报文就开始了一个报文就能学到全部加速信息。但是是否创建加速表项取决于包速率是否达到阈值。整个学习过程对用户来说几乎无感知高速流量通常在几个报文内就能达到阈值并进入加速。3. 芯片学了什么加速学习的核心是记录一条数据流的完整转发特征以便芯片能复现内核的处理结果。基本信息所有芯片都会学学习内容说明五元组源 IP、目的 IP、源端口、目的端口、协议号——用来唯一标识一条数据流出接口报文应该从哪个物理口/逻辑口转发出去MAC 头信息转发时需要使用的源 MAC 和目的 MAC三层转发需要重新封装扩展信息不同芯片差异较大学习内容说明芯片支持情况mark 值内核中通过 ebtables/iptables 打的 skb-markMTK 支持部分芯片可能不支持VLAN tag报文需要携带的 VLAN 标签大部分芯片支持NAT 信息SNAT/DNAT 的地址和端口映射大部分芯片支持报文特定字段某些芯片会学习报文的特殊字段信息MTK 等芯片支持⚠️不同芯片的学习能力差异很大。比如 MTK 的加速引擎可以学到 mark 值这使得基于 mark 的限速方案见上一篇文章可以在加速后依然生效。但如果某款芯片不支持学习 mark那基于 mark 的方案就需要换思路。选型时务必确认芯片 SDK 的加速学习能力支持哪些字段这直接影响功能方案的设计。4. 加速表容量与管理芯片内部维护一张加速表也叫流表、连接跟踪表每学习一条流就会创建一个表项。表项容量维度说明典型容量不同芯片差异大常见的有 4K4096 条、8K、16K 等每条表项代表一条数据流由五元组唯一标识表满了会怎样新的流无法加速会一直走 Linux 内核软件转发直到有旧表项被老化释放表满的影响当加速表满了新的数据流无法创建加速表项只能走内核软件转发。这会导致CPU 负载升高——软件转发比硬件加速消耗更多的 CPU转发性能下降——软件转发的吞吐量远低于硬件加速用户体验变差——可能出现卡顿、延迟增加在实际产品中家庭路由器的 4K 表项一般够用家里不会同时有上千条活跃连接。但如果设备下挂大量终端比如企业场景或者用户使用 P2P 下载一个 BT 任务就可能产生数百条连接加速表就可能被打满。5. 老化机制加速表项的生命周期加速表项不会永远存在有一套老化aging机制来管理表项的生命周期。超时老化每条加速表项都有一个老化计时器。如果在一定时间内没有匹配到报文也就是这条流没有新的数据包表项就会被自动清除。加速表项创建 → 有报文命中 → 重置老化计时器 → 继续加速 ↓ (超时无报文) 老化计时器到期 → 表项清除 → 释放资源协议感知老化除了超时老化芯片/SDK 还支持一些协议感知的快速老化场景老化行为TCP FIN/RST检测到 TCP 连接终止立即或快速老化该条目不等超时UDP 流停止无法主动感知只能等超时老化手动清除SDK 提供接口可以主动删除指定表项比如限速规则变更时需要清除旧的加速表项TCP FIN 立即老化是一个很实用的特性。当一个 TCP 连接正常关闭时对应的加速表项会被快速释放不会占着资源等超时。这对加速表容量有限的低端芯片尤其重要。6. 完整的生命周期图一条新的 TCP 连接 │ ▼ 第1个包 → 进入内核 → 完整处理bridge/route/hook/NAT │ │ │ SDK 学习转发特征 │ (五元组 mark MAC 出接口...) │ │ │ 创建加速表项 │ │ ▼ ▼ 前几个包继续走内核 加速表项就绪 │ │ ▼ ▼ 后续包 → 芯片查加速表 → 命中 → 芯片直接转发不经过内核 │ │ │ 重置老化计时器 │ ▼ (连接结束) TCP FIN/RST → 芯片感知 → 立即老化表项 → 释放资源 或 长时间无报文 → 老化计时器到期 → 清除表项 → 释放资源7. 不同芯片平台的差异总结对比维度海思联发科MTKRealtek学习触发第一个包即触发第一个包即触发第一个包即触发基本学习内容五元组 出接口 MAC五元组 出接口 MAC五元组 出接口 MAC扩展学习mark 等视具体型号支持 mark、报文字段等视具体型号加速表容量因型号而异因型号而异常见 4K-16K因型号而异TCP FIN 快速老化支持支持支持⚠️提示以上对比基于作者实际接触的芯片型号不同型号/不同 SDK 版本之间可能有差异。在实际开发中务必参考芯片厂商的 SDK 文档确认具体能力。8. 开发中的实用建议1.功能设计前先确认芯片学习能力——你的方案依赖 markVLANNAT先确认芯片能不能学到这些字段否则加速后功能会失效2.注意加速表容量——如果产品会下挂大量终端或用户有 P2P 需求要提前评估加速表是否够用3.配置变更时记得清加速表项——比如修改了限速规则旧的加速表项还按老的 mark 在转发需要主动清除让流重新学习4.调试时善用关闭加速——遇到转发异常先关掉硬件加速看问题是不是在内核侧这是最快的定位方法5.留意 TCP FIN 老化——如果你发现 TCP 短连接场景下加速表翻转很快这是正常的FIN 触发了快速老化作者按本文基于海思、联发科MTK、Realtek 三家芯片平台的实际开发经验。加速学习机制是 终端路由器转发面的核心设计理解它对于排查转发问题、设计功能方案都至关重要。