17.8. 接收中斷緩解

17.8.?接收中斷緩解

當(dāng)一個網(wǎng)絡(luò)驅(qū)動如我們上面所述編寫出來, 你的接口收到每個報文都中斷處理器. 在許多情況下, 這是希望的操作模式, 它不是個問題. 然而, 高帶寬接口能夠在每秒內(nèi)收到幾千個報文. 這個樣子的中斷負(fù)載下, 系統(tǒng)的整體性能會受損害.

作為一個提高高端 Linux 系統(tǒng)性能的方法, 網(wǎng)絡(luò)子系統(tǒng)開發(fā)者已創(chuàng)建了一種可選的基于查詢的接口(稱為 NAPI). [52]"查詢"可能是一個不妥的字在驅(qū)動開發(fā)者看來, 他們常?？吹讲樵兪遣混`巧和低效的. 查詢是低效的, 但是, 僅僅在接口沒有工作做的時候被查詢. 當(dāng)系統(tǒng)有一個處理大流量的高速接口時, 會一直有更多的報文來處理. 在這種情況下沒有必要中斷處理器; 時常從接口收集新報文是足夠的.

停止接收中斷能夠減輕相當(dāng)數(shù)量的處理器負(fù)載. 適應(yīng) NAPI 的驅(qū)動能夠被告知不要輸送報文給內(nèi)核, 如果這些報文只是在網(wǎng)絡(luò)代碼里因擁塞而被丟棄, 這樣能夠在最需要的時候?qū)π阅苡袔椭? 由于各種理由, NAPI 驅(qū)動也比較少可能重排序報文.

不是所有的設(shè)備能夠以 NAPI 模式操作, 但是. 一個 NAPI 適應(yīng)的接口必須能夠存儲幾個報文( 要么在接口卡上, 要么在內(nèi)存內(nèi) DMA 環(huán)). 接口應(yīng)當(dāng)能夠禁止中斷來接收報文, 卻可以繼續(xù)因成功發(fā)送或其他事件而中斷. 有其他微妙的事情使得編寫一個適應(yīng) NAPI 的驅(qū)動更有難度; 詳情見內(nèi)核源碼中的 Documentation/networking/NAPI_HOWTO.txt.

相對少有驅(qū)動實(shí)現(xiàn) NAPI 接口. 如果你在編寫一個驅(qū)動給一個可能產(chǎn)生大量中斷的接口, 但是, 花點(diǎn)時間來實(shí)現(xiàn) NAPI 會被證明是很值得的.

snull 驅(qū)動, 當(dāng)用非零的 use_napi 參數(shù)加載時, 在 NAPI 模式下操作. 在初始化時, 我們不得不建立一對格外的結(jié)構(gòu) net_device 的成員:

if (use_napi) {
    dev->poll  = snull_poll;
    dev->weight  = 2;
}

poll 成員必須設(shè)置為你的驅(qū)動的查詢函數(shù); 我們簡短看一下 snull_poll. weight 成員描述接口的相對重要性: 有多少流量可以從接口收到, 當(dāng)資源緊張時. 如何設(shè)置 weight 參數(shù)沒有嚴(yán)格的規(guī)則; 依照慣例, 10 MBps 以太網(wǎng)接口設(shè)置 weight 為 16, 而快一些的接口使用 64. 你不能設(shè)置 weight 為一個超過你的接口能夠存儲的報文數(shù)目的值. 在 snull, 我們設(shè)置 weight 為 2, 作為一個演示不同報文接收的方法.

創(chuàng)建適應(yīng) NAPI 的驅(qū)動的下一步是改變中斷處理. 當(dāng)你的接口(它應(yīng)當(dāng)在接收中斷使能下啟動)示意有報文到達(dá), 中斷處理不應(yīng)當(dāng)處理這個報文. 相反, 它應(yīng)當(dāng)禁止后面的接收中斷并告知內(nèi)核到時候查詢接口了. 在 snull的"中斷"處理里, 響應(yīng)報文接收中斷的代碼已變?yōu)槿缦?

if (statusword & SNULL_RX_INTR) {
    snull_rx_ints(dev, 0); /* Disable further interrupts */
    netif_rx_schedule(dev);
}

當(dāng)接口告訴我們有報文來了, 中斷處理將其留在接口中; 此時需要的所有東西就是調(diào)用 netif_rx_schedule, 它使得我們的 poll 方法在后面某個時候被調(diào)用.

poll 方法有下面原型:

int (*poll)(struct net_device *dev, int *budget); 

snull 的 poll 方法實(shí)現(xiàn)看來如此:

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;

}

函數(shù)的中心部分是關(guān)于創(chuàng)建一個保持報文的 skb; 這部分代碼和我們之前在 snull_rx 中見到的一樣. 但是, 有些東西不一樣:

• budget 參數(shù)提供了一個我們允許傳給內(nèi)核的最大報文數(shù)目. 在設(shè)備結(jié)構(gòu)里, quota 成員給出了另一個最大值; poll 方法必須遵守這兩個限制中的較小者. 它也應(yīng)當(dāng)以實(shí)際收到的報文數(shù)目遞減 dev->quota 和 *budget. budget 值是當(dāng)前 CPU 能夠從所有接口收到的最多報文數(shù)目, 而 quota 是一個每接口值, 常常在初始化時安排給接口以 weight 為起始.

• 報文應(yīng)當(dāng)用 netif_receive_skb 遞交內(nèi)核, 而不是 netif_rx.

• 如果 poll 方法能夠在給定的限制內(nèi)處理所有的報文, 它應(yīng)當(dāng)重新使能接收中斷, 調(diào)用 netif_rx_complete 來關(guān)閉 查詢, 并且返回 0. 返回值 1 指示有剩下的報文需要處理.

網(wǎng)絡(luò)子系統(tǒng)保證任何給定的設(shè)備的 poll 方法不會在多于一個處理器上被同時調(diào)用. 但是, poll 調(diào)用仍然可以與你的其他設(shè)備方法的調(diào)用并發(fā).

[52] NAPI 代表"new API"; 網(wǎng)絡(luò)黑客們精于創(chuàng)建接口卻疏于給它們起名.