IRQ Coalesce之前NAPI有哪些优势？

Question

众所周知,有两种方法可以避免高负载网络中的硬件中断的一些开销,当硬件中断太多时,切换到它们需要花费太多时间.对于程序风格的性能和选择方法非常重要.

1. NAPI(新API) - 不使用硬件中断,并且每隔一段时间轮询以太网设备.Linux内核默认使用中断驱动模式,只有当传入数据包流量超过某个阈值时才切换到轮询模式.

http://en.wikipedia.org/wiki/New_API 内核可以定期检查传入网络数据包的到达而不会中断,从而消除了中断处理的开销.

2. 中断合并 - 使用硬件中断,但如果发生中断,则禁用中断并开始轮询,持续一段时间,然后轮询终止并激活中断.

https://en.wikipedia.org/wiki/Interrupt_coalescing一种技术,在这种技术中,通常会触发硬件中断的事件会被阻止,直到一定量的工作挂起或超时计时器触发为止.

两种方法都没有显着的中断成本 - 这是默认中断驱动模式的优势.

但第二种方法 - 中断合并更合理,因为它:

• 减少延迟 - 一旦程序包到达,立即尝试立即处理它,如果最近发生了中断,则立即轮询它.NAPI对面不会立即处理帧,但会等待一段时间进行下一次轮询.

• 较少的CPU使用率 - 仅在至少有一个数据包到来时才开始轮询.但即使没有收到框架,也不是徒劳无功,就好像是NAPI一样.

IRQ Coalesce之前NAPI有哪些优势？

Answer 1

我将NAPI视为中断合并的一种形式.我认为你的问题可能源于对NAPI的误解.首先,NAPI涉及中断.此外,NAPI的民意调查实际上并非"徒劳".请记住,对于NAPI,其想法是高吞吐量流量是突发性的.NAPI仅在"数据包接收中断"发生后"启动".

以下是如何使用NAPI的快速概述:

内核启动"数据包接收"中断,使用NAPI的网络设备驱动程序检测到该中断.然后,网络设备驱动程序禁用与接收数据包相关的中断并使用NAPI,告诉Linux网络子系统轮询设备驱动程序.poll函数由设备驱动程序实现,并传递给网络子系统,并包含设备驱动程序的数据包处理程序.收到足够的数据包或达到超时后,重新启用数据包接收中断,一切都重新开始.

因此,NAPI基本上只是Linux网络子系统中的集中式API,用于支持中断合并以减少接收活锁情况.NAPI为设备驱动程序开发人员提供了一个干净的中断合并框架.NAPI不会一直运行,但只会在实际收到流量时发生,这使它基本上成为一个中断合并方案......至少在我的书中.

注意:这都是在使用NAPI的网络设备驱动程序的上下文中,但实际上NAPI可用于任何类型的中断.这也是NAPI的优势之一.

如果我的理解有任何错误,请随时指出!