開(kāi)啟NAPI的時(shí)候，是否需要關(guān)RX中斷？

帥絕人寰

哥暈了， e100、e1000、8139too、atl1c都是關(guān)的， 但igb不關(guān)！

按道理，調(diào)用napi_schedule/__napi_schedule之前， 是不是應(yīng)該關(guān)掉intr？

瀚海書(shū)香

回復(fù) 1# 帥絕人寰
呵呵，還是放心不下內(nèi)核啊
大體上看了下igb-2.4.8的源碼。的確是沒(méi)有關(guān)閉中斷。但是igb的README中有一段是描述關(guān)于interrupthrottlerate的，就是說(shuō)網(wǎng)卡會(huì)限制每秒中斷的次數(shù)。
在調(diào)用napi_schedule之前，會(huì)調(diào)用igb_write_itr，猜測(cè)這個(gè)函數(shù)會(huì)限制中斷的次數(shù)。

   

Godbach

呵呵，還是放心不下內(nèi)核啊

呵呵，學(xué)習(xí)內(nèi)核是一種習(xí)慣

crspo

回復(fù) 1# 帥絕人寰


    關(guān)了吧：

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. }
    

復(fù)制代碼

crspo

回復(fù) 4# crspo


    看成ixgb了，我在看看igb.

帥絕人寰

哪位兄弟幫我看看這個(gè)疑問(wèn)：

        -> 進(jìn)入Polling模式的時(shí)機(jī)
           關(guān)閉中斷、進(jìn)入Polling模式的時(shí)機(jī)，對(duì)Solaris而言，完全是adaptive的：上層決定，
           driver作者不用關(guān)心，只需提供xxx_intr_{disable|enable} 回調(diào)函數(shù)即可。

           而對(duì)Linux，需要由driver的ISR自己決定什么時(shí)候關(guān)RX中斷、調(diào)用napi_schedule。
           FIXME: 我看到Linux的driver根本沒(méi)有判斷目前的狀態(tài)是不是需要進(jìn)入Polling，而是
                     ISR直接進(jìn)Polling。 這樣是沒(méi)道理的！ 低流量的情形下，非要從ISR直接進(jìn)
                  polling，收那么三兩個(gè)包后，又退出polling，扯淡呢？

瀚海書(shū)香

回復(fù) 6# 帥絕人寰

我看到Linux的driver根本沒(méi)有判斷目前的狀態(tài)是不是需要進(jìn)入Polling，而是
                     ISR直接進(jìn)Polling。 這樣是沒(méi)道理的！ 低流量的情形下，非要從ISR直接進(jìn)
                  polling，收那么三兩個(gè)包后，又退出polling，扯淡呢？

linux的確是這樣實(shí)現(xiàn)的。如果你開(kāi)啟了napi，那么網(wǎng)卡就是這個(gè)流程；要想應(yīng)對(duì)低流量的情況，可以把NAPI關(guān)掉啊

關(guān)鍵的問(wèn)題在于，NAPI的設(shè)計(jì)理念就是應(yīng)對(duì)大流量的情況的設(shè)計(jì)的。
   

帥絕人寰

瀚海書(shū)香 發(fā)表于 2012-01-13 15:52
回復(fù) 6# 帥絕人寰

linux的確是這樣實(shí)現(xiàn)的。如果你開(kāi)啟了napi，那么網(wǎng)卡就是這個(gè)流程；要想應(yīng)對(duì)低流量的 ...

這個(gè)解釋不能接受。為什么？ napi即使是為大流量設(shè)計(jì)的，也不意味著一定要始終開(kāi)啟。 這個(gè)設(shè)計(jì)應(yīng)該是adaptive的，不應(yīng)該這個(gè)樣子。  假如上層不能做到adaptive，網(wǎng)卡driver也完全可以根據(jù)硬件statistics來(lái)決定什么時(shí)候進(jìn)入polling模式，而不是 無(wú)論什么情形都polling。 這對(duì)低流浪、要求low latency的情形根本是胡鬧�。�

瀚海書(shū)香

回復(fù) 8# 帥絕人寰
呵呵。LZ是完美主義者（軟件設(shè)計(jì)的就要有這樣的思想）
你所說(shuō)的NAPI會(huì)影響low latency，個(gè)人不太認(rèn)同。
1.開(kāi)啟NAPI會(huì)降低其他中斷類型的延遲，尤其是大流量的情況，小流量的情況雖然不會(huì)降低，但也不至于增加其他中斷的延遲。
2.開(kāi)啟NAPI會(huì)增大數(shù)據(jù)包硬中斷處理的延遲。不過(guò)需要明確的是，使用中斷模式，雖然能夠降低網(wǎng)卡硬中斷處理的延遲，但是由于數(shù)據(jù)包的后續(xù)處理還是在軟中斷中執(zhí)行的，相應(yīng)來(lái)說(shuō)并不會(huì)降低數(shù)據(jù)包在軟中斷和應(yīng)用層被處理的延遲。

內(nèi)核這塊的確的是處理的不好，但是底是沒(méi)考慮到？還是改動(dòng)的話會(huì)引入更多的問(wèn)題？個(gè)人更傾向于后者

   

遲到千年

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);
        }
請(qǐng)問(wèn)最后這里的判斷是重新打開(kāi)網(wǎng)卡接收中斷嗎？為什么一個(gè)napi結(jié)構(gòu)體處理完之后就要打開(kāi)了呢？這個(gè)napi結(jié)構(gòu)體和網(wǎng)卡或者隊(duì)列的對(duì)應(yīng)關(guān)系是什么�。吭诰W(wǎng)上沒(méi)有看到明確的說(shuō)法？是一個(gè)網(wǎng)卡對(duì)應(yīng)一個(gè)napi結(jié)構(gòu)體還是一個(gè)隊(duì)列對(duì)應(yīng)一個(gè)napi結(jié)構(gòu)體�。吭诰�等，感謝！