多核处理器中基于轮询和中断的数据包处理方法
该查询与多核处理器中的数据包处理有关。数据包处理可以在 Linux 中进行，也可以在纯数据路径中进行。如果数据包处理应用程序在Linux上，那么它必须是基于中断的数据包处理以获得高性能，但如果数据包处理在纯数据路径（没有Linux）中，那么应该使用轮询以获得更高的性能，这是真的吗？如果是，为什么/如何？
This query is related with the packet processing in multicore processors. Packet processing can be either in Linux or pure datapath. Is it true that if the packet processing application is on Linux, then it must be interrupt based processing of packets for high performance, but if the packet processing is in pure datapath (without linux), then polling should be used to obtain higher performance ? If yes, Why/How?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
投票
我们到了吗？我们到了吗？我们到了吗？我们到了吗？我们到了吗？ ...
中断
完成后通知我。
因此，中断允许 CPU 执行其他工作，而轮询则避免了中断的开销（如果每秒被中断数万次，则这一点就很重要）。不同种类的高性能。
请注意，存在混合方法，即：在中断几毫秒后轮询，然后恢复中断。
Polling
Are we there yet? Are we there yet? Are we there yet? Are we there yet? Are we there yet? ...
Interrupts
Ping me when it's done.
So, interrupts allow the CPU to do other work, while polling avoids the overhead of interrupts (significant if you are getting interrupted tens of thousands of times a second). Different kinds of high performance.
Note there are hybrid aproaches, i.e: polling after interrupts for a few ms, before reverting to interrupts.
如果您使用的是多任务操作系统，则会进行轮询
具有延迟损失（如果数据包到达而另一个任务正在执行）
执行）。因此，您可以通过使用获得更好的吞吐量
此类系统上基于中断的方法。这是因为
中断机制可以提升上面数据路径的优先级
其他进程而不阻塞它们（如轮询更高优先级的进程）
任务将阻塞所有较低优先级的任务）。
如果您在没有操作系统的裸机嵌入式系统上运行，
应该能够使用轮询获得最佳吞吐量，因为 CPU
可以花费所有时间检查新数据包或作为处理
收到数据包的结果。这可以最大限度地减少延迟并分配
数据包处理的最大周期。调用中断
在这种情况下，处理程序会浪费周期并引入额外的复杂性；
因为CPU上没有运行任何其他东西，所以你所采取的任何周期都是一个周期
不用于数据路径。
请注意，这并不意味着应用程序的总性能是
更好或者任何特定的实现更快
轮询。这仅意味着达到了可能的最大吞吐量
通过投票。例如，如果您的应用程序需要执行大量操作
使用带有中断的 DMA 进行处理可能会获得更好的性能。
要知道在任何特定情况下轮询是否更快，很大程度上取决于
该案例的应用特点。
我不确定这个问题的“多核”方面是什么，但是
将 CPU 专用于 I/O 轮询以获得最小是有意义的
嵌入式多核系统中的延迟，尽管这也会
高度特定于应用。
正如 ninjalj 所指出的，混合方法可用于优化总体
更复杂场景下的性能。以上仅适用于
简单的情况。
If you're using a multitasking operating system then polling will come
with a latency penalty (if the packet arrives while another task is
executing). Therefore you can get better throughput by using an
interrupt-based approach on such systems. This is because the
interrupt mechanism can elevate the priority of the data path above
other processes without blocking them (as polling in a higher-priority
task would block all the lower priority tasks).
If you're running on a bare-metal embedded system without an OS you
should be able to get the best throughput using polling since the CPU
can spend all its time checking for new packets or do processing as a
result of receieved packets. This minimizes the latency and allocates
a maximum of cycles to the packet processing. Calling an interrupt
handler wastes cycles and introduces extra complexity in this case;
since nothing else is running on the CPU any cycle you take is a cycle
not used tending to the data path.
Note that this does not mean that total application performance is
better or that any particular implementation is faster with
polling. It only means that the max throughput possible is achieved
through polling. For example, if your application needs to do lots of
processing you might get better performance using DMA with interrupts.
To know if polling is faster in any particular case depends heavily on
the application characteristics of that case.
I'm not sure what the "multicore" aspect of this question is, but
it can make sense to dedicate a CPU to I/O polling to get mimimum
latency in an embedded multicore system although this too would be
highly application specific.
As ninjalj notes, hybrid approaches can be used to optimize total
performance in more complex scenarios. The above only holds for the
simple case.