@qsnow6 主要是看实现代码和相关文档。https://docs.kernel.org/networking/nf_flowtable.html

You can identify hardware offloaded flows through the [HW_OFFLOAD] tag when listing your connection tracking table. Please, note that the [OFFLOAD] tag refers to the software offload mode, so there is a distinction between [OFFLOAD] which refers to the software flowtable fastpath and [HW_OFFLOAD] which refers to the hardware offload datapath being used by the flow.

@crzidea 你贴的三个链接其中两个链接都是 software offload ，不是 hardware offload 。哎，不说了。

@crzidea
1.用 stable 版本。
2. 用 speedtest 测速的时候，使用命令 grep HW_OFFLOAD /proc/net/nf_conntrack 看看 HW offload 有没有生效。如果不生效，看看配置有没有设置进去，命令是 grep flow_offloading_hw /etc/config/firewall

@huangya 至于怎么打开，见 22 楼。还有你测速在路由器跑，这个是不准的。直接在路由器跑，非常有可能不能使用硬件加速，导致测速过低。需要用电脑跑。路由器只做 NAT 转发，然后路由器在转发的时候，会用到硬件加速。

楼主，mtk7621 openwrt 支持硬件 offload ，亲测可以跑满千兆，cpu 负载为 0. 要在页面上把它打开。

@TerryRobles
在我的使用场景下,
1.上升沿和下降沿都需要触发中断，因为我要用软件来计算按键持续时间的长度。区分是长按还是短按。
2.我现在是使用读 gpio 的值来区分是按下还是松开。

>按键一般不都是读取多次的吗？
3.在我的环境下，假设使用了硬件消除抖动，只需要读取一次。

基于上述我所说的几点，OP 在讨论一种可能的理论情况，第一次按键产生中断，然后程序读取 GPIO 的值的时候，有没有可能这个值由于键快速释放导致 GPIO 值变化了。这里还牵扯一个问题，就是什么时候读取。如果放到中断的 top half 这个概率就更小了，如果放到中断的 bottom half ，会不会概率增大很大。

@sujin190 嗯，能帮忙看下看下我在第 9 楼的回复中提到的细节问题吗？这个我也不需要担心吗？ 12 和 13 楼也是 9 楼相关问题。

@dalabenba 所以你的建议是在 top half 里面把 gpio 的值读到内存变量里面吗？

@billlee
>足够快的释放等于抖动，会直接被过滤掉。
好像也是。

>但树莓派上拿 python 写的所谓“中断处理程序”并不是真的，确实可能出现慢得离谱的情况。
我不是，我是用 C 写一个 kernel module.

@Alexsen 请允许我再问个细节问题。按照你的说法，不需要担心这种极端情况，那是不是也意味着我在 top half 读取 GPIO 值可以放到一个 static 全局变量，然后在 bottom half 读。我也不需要担心这个 static 全局变量被第二次中断覆盖。是吗？谢谢！

@crysislinux
>发生的概率太小外加发生了也没什么严重后果，就不需要去投入额外成本解决了

嗯，我猜可能是这样。但是还是想听听大家的意见，集思广益。似乎教科书或者网络上的大佬也没有讨论过。

@xiri

>也就是说你提到的按下/松开按钮的两个场景最终可以直接去调用不同的中断处理函数，而不用再去读一下 gpio 才能知道当前触发的模式

嗯，看起来是一种思路。嵌入式 linux 有的。可以使用 IRQF_TRIGGER_RISING 和 IRQF_TRIGGER_FALLING 来指定。但是我感觉这样会增加一些冗余代码，不是很简洁。

@paopjian 我只是想单个核的频率高。比如在运行的时候只有一个核能达到 5GHZ ，不需要两个核或以上在同一个时刻跑到 5GHZ 。这里有三个概念：
Base Clock
All Core Boost Speed
Max. Boost Clock

分别对应 1 楼说的“基频 3.3Ghz ，turbo 8 核 3.6Ghz ，单核 4.0Ghz ”

@adadada 我在中断处理加了这个函数(假设用 request_irq 申请的中断，在 handler 里面加的)，确实是返回 1 。
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
const char *name, void *dev)

@Kumo31 你的意思是在 qemu 里面 dump 相关寄存器吧？嗯，这是个办法。

@RecursiveG 确实有点不同我以往的认知，搜索了一下，似乎也有很多人说既不是数字也不是说模拟。
https://www.quora.com/Is-an-ethernet-cable-digital-or-analogue

>然而，我在默认 1420 下用的一点毛病也没有 连日本 aws 能跑到 100M ，几乎没有断流的现象。所以这个点让我有点困惑，不知道需不需要调整，还是说 routeros 对 wireguard 是有处理的？

你可以在 aws 那边抓下包看下有没有收到最大为 1500 的包。也可以看下解密之后的包（也就是脱掉 wg 层）的 mss(tcp 场景）是多少

@RecursiveG 网线使用的双绞线难道不是模拟信号吗?

@zmcity 我的理解是从路由器的 sfp 口（ mac 层）出来是数字信号，dac 是有个芯片的，没有芯片的话，数字信号是传不了几米的。在 dac 线里面传输的应该是模拟信号。