Chinaunix

标题: 开启NAPI的时候，是否需要关RX中断？ [打印本页]

作者: 帅绝人寰 时间: 2012-01-11 13:06
标题: 开启NAPI的时候，是否需要关RX中断？

哥晕了， e100、e1000、8139too、atl1c都是关的，但igb不关！

按道理，调用napi_schedule/__napi_schedule之前，是不是应该关掉intr？

作者: 瀚海书香 时间: 2012-01-12 08:57
回复 1# 帅绝人寰
呵呵，还是放心不下内核啊

大体上看了下igb-2.4.8的源码。的确是没有关闭中断。但是igb的README中有一段是描述关于interrupthrottlerate的，就是说网卡会限制每秒中断的次数。
在调用napi_schedule之前，会调用igb_write_itr，猜测这个函数会限制中断的次数。

作者: Godbach 时间: 2012-01-12 09:49

呵呵，还是放心不下内核啊

呵呵，学习内核是一种习惯

作者: crspo 时间: 2012-01-12 15:26
回复 1# 帅绝人寰

关了吧：

static irqreturn_t
ixgb_intr(int irq, void *data)
{
struct net_device *netdev = data;
struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
u32 icr = IXGB_READ_REG(hw, ICR);
if (unlikely(!icr))
return IRQ_NONE; /* Not our interrupt */
if (unlikely(icr & (IXGB_INT_RXSEQ | IXGB_INT_LSC)))
if (!test_bit(__IXGB_DOWN, &adapter->flags))
mod_timer(&adapter->watchdog_timer, jiffies);
if (napi_schedule_prep(&adapter->napi)) {
/* Disable interrupts and register for poll. The flush
of the posted write is intentionally left out.
*/
IXGB_WRITE_REG(&adapter->hw, IMC, ~0);
__napi_schedule(&adapter->napi);
}
return IRQ_HANDLED;
}

复制代码

作者: crspo 时间: 2012-01-12 15:28
回复 4# crspo

看成ixgb了，我在看看igb.

作者: 帅绝人寰 时间: 2012-01-13 12:10
哪位兄弟帮我看看这个疑问：

-> 进入Polling模式的时机
   关闭中断、进入Polling模式的时机，对Solaris而言，完全是adaptive的：上层决定，
   driver作者不用关心，只需提供xxx_intr_{disable|enable} 回调函数即可。

   而对Linux，需要由driver的ISR自己决定什么时候关RX中断、调用napi_schedule。
   FIXME: 我看到Linux的driver根本没有判断目前的状态是不是需要进入Polling，而是
      ISR直接进Polling。这样是没道理的！低流量的情形下，非要从ISR直接进
   polling，收那么三两个包后，又退出polling，扯淡呢？

作者: 瀚海书香 时间: 2012-01-13 15:52
回复 6# 帅绝人寰

我看到Linux的driver根本没有判断目前的状态是不是需要进入Polling，而是
ISR直接进Polling。这样是没道理的！低流量的情形下，非要从ISR直接进
polling，收那么三两个包后，又退出polling，扯淡呢？

linux的确是这样实现的。如果你开启了napi，那么网卡就是这个流程；要想应对低流量的情况，可以把NAPI关掉啊

关键的问题在于，NAPI的设计理念就是应对大流量的情况的设计的。

作者: 帅绝人寰 时间: 2012-01-13 21:22

瀚海书香发表于 2012-01-13 15:52
回复 6# 帅绝人寰

linux的确是这样实现的。如果你开启了napi，那么网卡就是这个流程；要想应对低流量的 ...

这个解释不能接受。为什么？ napi即使是为大流量设计的，也不意味着一定要始终开启。这个设计应该是adaptive的，不应该这个样子。假如上层不能做到adaptive，网卡driver也完全可以根据硬件statistics来决定什么时候进入polling模式，而不是无论什么情形都polling。这对低流浪、要求low latency的情形根本是胡闹啊！

作者: 瀚海书香 时间: 2012-01-14 07:49
回复 8# 帅绝人寰
呵呵。LZ是完美主义者（软件设计的就要有这样的思想）

你所说的NAPI会影响low latency，个人不太认同。
1.开启NAPI会降低其他中断类型的延迟，尤其是大流量的情况，小流量的情况虽然不会降低，但也不至于增加其他中断的延迟。
2.开启NAPI会增大数据包硬中断处理的延迟。不过需要明确的是，使用中断模式，虽然能够降低网卡硬中断处理的延迟，但是由于数据包的后续处理还是在软中断中执行的，相应来说并不会降低数据包在软中断和应用层被处理的延迟。

内核这块的确的是处理的不好，但是底是没考虑到？还是改动的话会引入更多的问题？个人更倾向于后者

作者: 迟到千年 时间: 2024-08-30 15:09
if (work_done < budget) {
if (likely(adapter->itr_setting & 3))
e1000_set_itr(adapter);
napi_complete(napi);
if (!test_bit(__E1000_DOWN, &adapter->flags))
e1000_irq_enable(adapter);
}
请问最后这里的判断是重新打开网卡接收中断吗？为什么一个napi结构体处理完之后就要打开了呢？这个napi结构体和网卡或者队列的对应关系是什么啊？在网上没有看到明确的说法？是一个网卡对应一个napi结构体还是一个队列对应一个napi结构体啊？在线等，感谢！

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)