LWN：把NAPI轮询改为使用kernel threads！

关注了就能看到更多这么棒的文章哦～

NAPI polling in kernel threads

By Jonathan Corbet
October 9, 2020
DeepL assisted translation
https://lwn.net/Articles/833840/

在那些需要进行大量网络传输的系统中，最终会花很大一部分 CPU 时间在网络协议栈（network stack）这里。这里的工作大多是在软中断上下文（software-interrupt context）里完成的，这种做法会有几个缺点。不过，等 Wei Wang 发布的这组 patch 合并到 mainline 里，情况就会改变了。

在一个数据包到达网络接口的之后，内核通常需要执行相当多的协议处理（protocol-processing）工作，然后才能将该数据包中的数据传递给正在等待它的用户空间应用程序。很早以前，当一个数据包到达时，网络接口会给 CPU 发个中断，Linux kernel 会先对这个中断进行确认，然后触发一个软中断来进行处理。这种方法有个缺点，在繁忙的系统中，每秒钟可能会有成千上万的数据包到达，对这成千上万的硬件中断进行处理会把系统的资源都用光。

这个问题在 2003 年得到了解决，也就是合入了一种新的机制，当时被称为 "new API "或 "NAPI"。支持 NAPI 的驱动程序支持大部分时间里关闭数据包接收中断，而是依靠网络协议栈频繁轮询新来的数据包。轮询（polling）一般给人的印象都是效率不高，但在繁忙的系统中，当内核轮询查看是否有新数据包时，多数时候都能看到有新的数据包在等着处理，这样一来，驱动程序可以一次性处理所有在等待的数据包。采用这种方式之后，轮询一次，就可以替代几十个硬件中断。

自 2003 年以来，NAPI 又有了很多演进，但有一点是不变的：它仍然以软中断（software-interrupt）模式运行。内核只要触发了这些软中断，它们就会在下一次硬件中断返回时、或者下一次内核切换到用户模式的时候得到处理。因此，它们的运行时机实际上是随机的，会从任何与它无关的进程中偷时间。软中断对于系统管理员来说是很难管理的，如果它们长时间运行，会导致出乎意料的 latency。因此，内核开发者多年来一直想减少或消除软中断的使用。不过它们是一种很古老的机制，内核的核心部分还一直在用它，很难完全去除。

Wang 的 patch set（包含 Paolo Abeni、Felix Fietkau 和 Jakub Kicinski 的工作）并没有去除掉软中断，但这是朝着这个方向走的一步。在打上这些 patch 之后，内核可以选择（管理员才有这个权限）为每一个支持 NAPI 的网络接口创建一个单独的内核线程。之后，NAPI 轮询将在该线程的上下文中进行，而不是在软中断中进行。

在经过这个 patch set 改动之后，网络包处理需要完成的工作量基本上没有变化，只有在工作方式方面有了显著的变化。等把 NAPI 轮询转到自己的内核线程中之后，管理员就更容易观测到它的行为，也更好对它进行控制。内核线程可以改变优先级，并且可以绑定到一组特定的 CPU 上，这使得管理员可以调整它和系统中用户空间的相关工作的关联。同时，CPU 的 scheduler 将更好地了解 NAPI 轮询所需的 CPU 时间，并能避免其运行的 CPU 负担过重。而之前处理软中断所花费的时间，scheduler 几乎是意识不到的。

patch set 发布出来的性能测试数据并不多，有部分结果表明，在使用线程模式时，开销可能略有增加。高速处理数据包的用户往往会想尽办法来省下每一纳秒的时间。从这些测试结果来看，哪怕是这些斤斤计较的用户，可能也不会抱怨太多。同时，这些用户也应该看到他们用户空间代码的调度行为有了更多的确定性，这也是很重要的。

网络开发人员似乎普遍支持这项工作，Eric Dumazet 表示希望尽快将其合并。不过并不是没有其他声音的，特别是 Kicinski，他不喜欢使用内核线程，认为使用内核的 workqueue 机制进行轮询来取代线程，可以获得更好的性能。Dumazet 回答说，workqueue 在 "server class platforms（服务器级别平台）" 上的表现不会很好，并表示没有兴趣在将来让 Linux 再实现一个基于 workqueue 的解决方案。

因此，这项工作预计很快就会被合并。八成已经赶不上 5.10 了，所以很可能会被包含在 5.11 内核中。值得注意的是，线程模式默认是关闭的。要想利用好这个功能，几乎肯定需要对系统进行细致地调优，以确保 NAPI 线程运行时能够不给工作负载带来负面影响。目前来说，不愿意或不能进行系统细致调优的管理员，建议继续使用默认的软中断模式。软中断本身仍然不会很快被移除，但是本工作可能有助于这个“移除软中断”的长期任务。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～