开启NAPI的时候，是否需要关RX中断？

帅绝人寰

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

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

瀚海书香

回复 1# 帅绝人寰
呵呵，还是放心不下内核啊
大体上看了下igb-2.4.8的源码。的确是没有关闭中断。但是igb的README中有一段是描述关于interrupthrottlerate的，就是说网卡会限制每秒中断的次数。
在调用napi_schedule之前，会调用igb_write_itr，猜测这个函数会限制中断的次数。

   

Godbach

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

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

crspo

回复 1# 帅绝人寰


    关了吧：

1. static irqreturn_t
   
2. ixgb_intr(int irq, void *data)
   
3. {
   
4.         struct net_device *netdev = data;
   
5.         struct ixgb_adapter *adapter = netdev_priv(netdev);
   
6.         struct ixgb_hw *hw = &adapter->hw;
   
7.         u32 icr = IXGB_READ_REG(hw, ICR);
   
8. 
   
9.         if (unlikely(!icr))
   
10.                 return IRQ_NONE;  /* Not our interrupt */
    
11. 
    
12.         if (unlikely(icr & (IXGB_INT_RXSEQ | IXGB_INT_LSC)))
    
13.                 if (!test_bit(__IXGB_DOWN, &adapter->flags))
    
14.                         mod_timer(&adapter->watchdog_timer, jiffies);
    
15. 
    
16.         if (napi_schedule_prep(&adapter->napi)) {
    
17. 
    
18.                 /* Disable interrupts and register for poll. The flush
    
19.                   of the posted write is intentionally left out.
    
20.                 */
    
21. 
    
22.                 IXGB_WRITE_REG(&adapter->hw, IMC, ~0);
    
23.                 __napi_schedule(&adapter->napi);
    
24.         }
    
25.         return IRQ_HANDLED;
    
26. }
    

复制代码

crspo

回复 4# crspo


    看成ixgb了，我在看看igb.

帅绝人寰

哪位兄弟帮我看看这个疑问：

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

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

瀚海书香

回复 6# 帅绝人寰

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

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

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

帅绝人寰

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

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

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

瀚海书香

回复 8# 帅绝人寰
呵呵。LZ是完美主义者（软件设计的就要有这样的思想）
你所说的NAPI会影响low latency，个人不太认同。
1.开启NAPI会降低其他中断类型的延迟，尤其是大流量的情况，小流量的情况虽然不会降低，但也不至于增加其他中断的延迟。
2.开启NAPI会增大数据包硬中断处理的延迟。不过需要明确的是，使用中断模式，虽然能够降低网卡硬中断处理的延迟，但是由于数据包的后续处理还是在软中断中执行的，相应来说并不会降低数据包在软中断和应用层被处理的延迟。

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