17.8. 接收中斷緩解 · Linux 設備驅動 (第三版)

## 17.8.?接收中斷緩解當一個網絡驅動如我們上面所述編寫出來, 你的接口收到每個報文都中斷處理器. 在許多情況下, 這是希望的操作模式, 它不是個問題. 然而, 高帶寬接口能夠在每秒內收到幾千個報文. 這個樣子的中斷負載下, 系統的整體性能會受損害. 作為一個提高高端 Linux 系統性能的方法, 網絡子系統開發者已創建了一種可選的基于查詢的接口(稱為 NAPI). [[52](#)]"查詢"可能是一個不妥的字在驅動開發者看來, 他們常常看到查詢是不靈巧和低效的. 查詢是低效的, 但是, 僅僅在接口沒有工作做的時候被查詢. 當系統有一個處理大流量的高速接口時, 會一直有更多的報文來處理. 在這種情況下沒有必要中斷處理器; 時常從接口收集新報文是足夠的. 停止接收中斷能夠減輕相當數量的處理器負載. 適應 NAPI 的驅動能夠被告知不要輸送報文給內核, 如果這些報文只是在網絡代碼里因擁塞而被丟棄, 這樣能夠在最需要的時候對性能有幫助. 由于各種理由, NAPI 驅動也比較少可能重排序報文. 不是所有的設備能夠以 NAPI 模式操作, 但是. 一個 NAPI 適應的接口必須能夠存儲幾個報文( 要么在接口卡上, 要么在內存內 DMA 環). 接口應當能夠禁止中斷來接收報文, 卻可以繼續因成功發送或其他事件而中斷. 有其他微妙的事情使得編寫一個適應 NAPI 的驅動更有難度; 詳情見內核源碼中的 Documentation/networking/NAPI_HOWTO.txt. 相對少有驅動實現 NAPI 接口. 如果你在編寫一個驅動給一個可能產生大量中斷的接口, 但是, 花點時間來實現 NAPI 會被證明是很值得的. snull 驅動, 當用非零的 use_napi 參數加載時, 在 NAPI 模式下操作. 在初始化時, 我們不得不建立一對格外的結構 net_device 的成員: ~~~ if (use_napi) { dev->poll = snull_poll; dev->weight = 2; } ~~~ poll 成員必須設置為你的驅動的查詢函數; 我們簡短看一下 snull_poll. weight 成員描述接口的相對重要性: 有多少流量可以從接口收到, 當資源緊張時. 如何設置 weight 參數沒有嚴格的規則; 依照慣例, 10 MBps 以太網接口設置 weight 為 16, 而快一些的接口使用 64. 你不能設置 weight 為一個超過你的接口能夠存儲的報文數目的值. 在 snull, 我們設置 weight 為 2, 作為一個演示不同報文接收的方法. 創建適應 NAPI 的驅動的下一步是改變中斷處理. 當你的接口(它應當在接收中斷使能下啟動)示意有報文到達, 中斷處理不應當處理這個報文. 相反, 它應當禁止后面的接收中斷并告知內核到時候查詢接口了. 在 snull的"中斷"處理里, 響應報文接收中斷的代碼已變為如下: ~~~ if (statusword & SNULL_RX_INTR) { snull_rx_ints(dev, 0); /* Disable further interrupts */ netif_rx_schedule(dev); } ~~~ 當接口告訴我們有報文來了, 中斷處理將其留在接口中; 此時需要的所有東西就是調用 netif_rx_schedule, 它使得我們的 poll 方法在后面某個時候被調用. poll 方法有下面原型: ~~~ int (*poll)(struct net_device *dev, int *budget); ~~~ snull 的 poll 方法實現看來如此: ~~~ static int snull_poll(struct net_device *dev, int *budget) { int npackets = 0, quota = min(dev->quota, *budget); struct sk_buff *skb; struct snull_priv *priv = netdev_priv(dev); struct snull_packet *pkt; while (npackets < quota && priv->rx_queue) { pkt = snull_dequeue_buf(dev); skb = dev_alloc_skb(pkt->datalen + 2); if (! skb) { if (printk_ratelimit()) printk(KERN_NOTICE "snull: packet dropped\n"); priv->stats.rx_dropped++; snull_release_buffer(pkt); continue; } memcpy(skb_put(skb, pkt->datalen), pkt->data, pkt->datalen); skb->dev = dev; skb->protocol = eth_type_trans(skb, dev); skb->ip_summed = CHECKSUM_UNNECESSARY; /* don't check it */ netif_receive_skb(skb); /* Maintain stats */ npackets++; priv->stats.rx_packets++; priv->stats.rx_bytes += pkt->datalen; snull_release_buffer(pkt); } /* If we processed all packets, we're done; tell the kernel and reenable ints */ *budget -= npackets; dev->quota -= npackets; if (! priv->rx_queue) { netif_rx_complete(dev); snull_rx_ints(dev, 1); return 0; } /* We couldn't process everything. */ return 1; } ~~~ 函數的中心部分是關于創建一個保持報文的 skb; 這部分代碼和我們之前在 snull_rx 中見到的一樣. 但是, 有些東西不一樣: - budget 參數提供了一個我們允許傳給內核的最大報文數目. 在設備結構里, quota 成員給出了另一個最大值; poll 方法必須遵守這兩個限制中的較小者. 它也應當以實際收到的報文數目遞減 dev->quota 和 *budget. budget 值是當前 CPU 能夠從所有接口收到的最多報文數目, 而 quota 是一個每接口值, 常常在初始化時安排給接口以 weight 為起始. - 報文應當用 netif_receive_skb 遞交內核, 而不是 netif_rx. - 如果 poll 方法能夠在給定的限制內處理所有的報文, 它應當重新使能接收中斷, 調用 netif_rx_complete 來關閉查詢, 并且返回 0. 返回值 1 指示有剩下的報文需要處理. 網絡子系統保證任何給定的設備的 poll 方法不會在多于一個處理器上被同時調用. 但是, poll 調用仍然可以與你的其他設備方法的調用并發. [[52](#)] NAPI 代表"new API"; 網絡黑客們精于創建接口卻疏于給它們起名.