路由器的硬件转发是否支持 pppoe 数据包的拆包和组包？

高端路由器是支持 ppoe 硬件加速的，我的理解是支持 nat 加速就支持 ppoe ，硬解 ppoe 是 nat 硬件加速的前置条件

不懂，只知道 pppoe 属于 tun 接口需要消耗 cpu ，实际测试性能还是远低于 br-wan 。
像 mtk7620 之前的版本连 100mbps 都跑不起来，但是当它更新到 openwrt 21.02.5 直接跑满 100mbps 还不知道上限在哪。而该设备在 br-wan 忘了是 400+mbps 还是 600+mbps 。

x86 软路由换成 b610-4e 直接拨号，单纯为了杜绝浪费

多虑了，pppoe 没有加密且头部固定，encap 和 decap 你就简单理解为 memcpy 了二三十个字节。
“硬件加速”可以简单理解为快慢路径，慢路径是 CPU ，快速路径是硬件，以一个最简单的，从你电脑 ping 1.1.1.1 来说，硬件上记录了两条表项，分别是正向 nat 和反向 nat ，
正向： 从 接口 A 进来的 源 IP 是 192.168.1.100 目的 IP 是 1.1.1.1 协议是 ICMP 的报文 NAT 成 源 IP100.64.0.11 （你 pppoe 接口的 IP ）目的 IP1.1.1.1 从接口 B （你的 wan 接口）出去
反向就是上面的表项反着下一条，来把 wan 收到的报文 nat 成你的 IP

想象一下这个过程：
1. 硬件表项需要 CPU 参与，流程简单描述是 硬件表项 miss ，upcall 到 cpu ，cpu 根据 iptables 的配置处理完成之后，下发到内核 conntrack ，再下发到硬件
2. 家用路由器硬件表项是有数量限制的，通常 16K 到 64K ，意思是超过这么大的连接数之后，就会超时老化置换掉一部分连接

硬件加速比软路由有优势的场景：
1. 连接数小且单个连接存活时间长且流量大

以上所有处理过程都是 ns 或者 us 级别，人肉不可感知，所以，直接用 x86 软路由，灵活性和可扩展性都吊打家用和中低端企业级路由器

力大砖飞，软路由没问题就别折腾，除非你是游戏直播玩家，长期需要小包转发

mtk 支持，跑 pppoe 完全不过 cpu

几十块的 mt7981 都支持 pppoe offload

如果一个处理逻辑可以标准化，那么大部分情况下就可以有造一个专有芯片来处理，比如 GPU 、TLS 加速芯片、交换机的交换芯片。mtk 的 hnat 对于这类情况直接 offload 到专有芯片处理，基本是处理器零占用。

提个场景问题：换 b610-4e 后王者的延迟会减少 1-5ms 吗？
如果完全没有换它的意义何在？

经验中延迟不该是 2 个网络设备的距离嘛。
而在 qos 中反应的是当前带宽的饱和程度，就如在同一根带宽划出 4 根水管，可以让高优先级的游戏做到小于 19ms ，同时让最低优先级的 p2p 以接近 100%分配的带宽通过延迟接近 600ms 。
还有无线和有线表现不一。

1-5ms 总要找一个对比的东西，1-5ms 这是用什么测出来，手里没这么精度的测试软件。
对于游戏至少电信对英雄联盟做了 qos ，反而本地 qos 配置不当导致延迟更高，另外 openwrt 下一直用的 sfq ，sqm 的那些技术延迟很好看，画面的实时性非常差，有一种飘移感。游戏想玩得好，一手机独占 ap 不会受其它终端信号强度引起 ap 呑吐变化带来延迟变化。

@ShioWSX 你为啥会有这种理解呢
PPPoE （注意是三个 P ）和 NAT 有啥关系？都不是同一层的

x86 软路由最大的问题是 linux 内核有 1mpps 的上限

只要在这个范围内，x86 软路由吊打一切硬路由，但是超过这个范围，最好用硬路由。

除非你用 DPDK 或者不用 linux 系统

或者启用网卡的硬件卸载，英伟达的 CX5 网卡开始就有硬件 NAT ，但是这本身就是硬路由的范畴了

X86 软路由下限很高，天花板很低。硬路由，下限可以很低，上限可以很高。

@ShioWSX PPPoE 加速和 NAT 加速是两个概念，根本不是一回事

@FabricPath 早在多年前就已经有人在 reddit 这类网站上问有没有 modem 支持 half-bridge 了，你猜是为什么

@skylancer 不用猜为啥，我自己用 xdp 撸一个 pppoe 报文转发，就几个 memcpy ，没发现难在什么地方。
你指的 nat 加速是指什么？你理解的 nat 加速是指，conntrack 不用 CPU 下发？