Linux5.1特性预告：NAPI轮询或将支持使用内核线程更多互联网新鲜资讯、工作奇

更多互联网新鲜资讯、工作奇淫技巧关注原创【飞鱼在浪屿】（日更新）
文章插图
管理大量网络流量的系统最终将其可用CPU时间的很大一部分，专门用于网络堆栈本身。这项工作大部分是在软件中断的环境下完成的，这在许多方面都可能造成问题。但是，一旦由Wei Wang发布的补丁系列（@google.com/）合并到主线后，情况可能会改变。
内核收发数据包原理：数据包到达网络接口后，内核通常必须执行大量协议处理工作，然后才能将该数据包中的数据传递到正在等待它的用户空间应用程序中。当数据包到达时，网络接口会中断CPU 。内核将确认该中断，然后触发软件中断以执行此处理工作。这种方法的问题在于，在繁忙的系统上，每秒可能有数千个数据包到达。处理相应的数千个硬件中断可将系统拖垮。
NAPI/间断轮询这个问题的解决方案在2003年以一种机制的形式被合并（），该机制当时被称为“新API”或“ NAPI” 。支持NAPI的驱动程序可以在大多数时间禁用数据包接收中断，并依靠网络堆栈以频繁的间隔轮询新数据包。轮询似乎效率低下，但是在繁忙的系统上，到内核轮询它们时，总会有新的数据包。然后，驱动程序可以立即处理所有等待的数据包。通过这种方式，一次轮询可以替换数十个硬件中断。
自2003年以来， NAPI有了长足的发展，但是一个方面仍然保持不变：它仍然以软件中断模式运行。这些中断一旦由内核排队，将在硬件中断的下一次返回或内核到用户模式的下一次返回时进行处理。因此，它们在本质上是在随机的上下文中运行，从而从当时不相关的任何进程中窃取时间。软件中断难以为系统管理员管理，并且如果运行很长时间，可能会产生令人惊讶的延迟。因此，内核开发人员多年来一直希望减少或消除其使用。但是，它们是一种古老的机制，已深入到内核的核心部分，并且很难摆脱。
内核线程替代软件中断Wang的补丁集（包含Paolo Abeni ， Felix Fietkau和Jakub Kicinski的著作）并没有消除软件中断，但是这可能是朝着这个方向迈出的一步。应用这些补丁后，内核可以选择（在管理员控制下）为每个启用NAPI的网络接口创建一个单独的内核线程。之后， NAPI轮询将在该线程的上下文中完成，而不是在软件中断中完成。
使用此补丁集，需要完成的工作量基本上没有变化，但是完成工作方式的变化是重大的。一旦NAPI轮询移动到其自己的内核线程，它就会变得更加可见并受管理员控制。内核线程可以更改其优先级，并且可以绑定到一组特定的CPU 。允许管理员根据系统的用户空间工作负载来调整工作方式。同时， CPU调度程序将更好地了解NAPI轮询需要多少CPU时间，并且可以避免正在运行的CPU过载。相反，调度程序几乎看不到处理软件中断所花费的时间。
性能测试在性能方面，以1000个流量运行了tcp_rr测试，各种请求/响应大小，禁用了RFS / RPS ，并进行了比较softirq与kthread之间的性能。主机有56个超线程， 100Gbps网卡。
(@google.com/)
req/resp QPS 50％tile 90％tile 99％tile 99.9％tilesoftirq 1B/1B 2.19M 284us 987us 1.1ms 1.56mskthread 1B/1B 2.14M 295us 987us 1.0ms 1.17mssoftirq 5KB/5KB 1.31M 869us 1.06ms 1.28ms 2.38mskthread 5KB/5KB 1.32M 878us 1.06ms 1.26ms 1.66mssoftirq 1MB/1MB 10.78K 84ms 166ms 234ms 294mskthread 1MB/1MB 10.83K 82ms 173ms 262ms 320ms补丁集发布的基准测试结果并不多；使用线程模式时，可用的指示开销可能会略有增加。以高速率处理数据包的用户往往对纳秒级的都很介意，但即使他们可能也很少质疑这些机制。因为其实这些用户还应该为其用户空间代码看到更多确定性的调度，这也很重要。
Linux5.1内核将采用它吗【Linux5.1特性预告：NAPI轮询或将支持使用内核线程】因此看来这项工作将很快合并。对于5.10来说已经很晚了，因此有可能用在5.11内核。值得注意的是，默认情况下线程模式将保持关闭状态。充分利用它几乎肯定需要进行系统调试，以确保NAPI线程能够在不干扰工作负载的情况下运行；就目前而言，不建议或不愿进行此调整的管理员最好还是建议使用默认的软件中断模式。软件中断本身仍然不会很快消失，但是这项工作可能有助于长期解决方案。