內(nèi)核netfilter處理問題(暨packet接受與NAPI介紹)

guotie

我認為，一個數(shù)據(jù)報在netfilter處理的過程中，一直是在softirq中進行的，因此，不可能被其他softirq打斷，

如果在一個netfilter的動作，也即target中，直接調(diào)用dev_queue_xmit()來發(fā)送自己構(gòu)造的數(shù)據(jù)報，會出現(xiàn)內(nèi)存泄漏嗎？

內(nèi)核中，一個最為接近的類似的處理是ipt_REJECT，單它使用NF的鉤子來發(fā)送自己的數(shù)據(jù)，而不是直接調(diào)用dev_queue_xmit()。

[ 本帖最后由 albcamus 于 2006-1-11 16:17 編輯 ]

wheelz

原帖由 guotie 于 2006-1-8 18:41 發(fā)表
我認為，一個數(shù)據(jù)報在netfilter處理的過程中，一直是在softirq中進行的，因此，不可能被其他softirq打斷，

如果在一個netfilter的動作，也即target中，直接調(diào)用dev_queue_xmit()來發(fā)送自己構(gòu)造的數(shù)據(jù)報，會出現(xiàn)內(nèi)存泄漏嗎？

1）報文在netfilter處理的過程中，不一定是在softirq中。比如本機發(fā)出的報文，可能在進程上下文中。

2）不會內(nèi)存泄露。倒不是說不可以用dev_queue_xmit()，但這樣就bypass了ARP協(xié)議等的處理，你必須自己構(gòu)造鏈路層楨頭。

xiaozhaoz

樓主的前提是錯誤的，報文的處理過程不一定在軟中斷中進行，即使是接收和ip層處理，請參考NAPI和softirqd代碼。當(dāng)接收報文長時間占用軟中斷后，會啟動softirqd內(nèi)核線程執(zhí)行報文處理。 內(nèi)核2.6.15-rt2

感覺樓主想要實現(xiàn)的東西和我以前做過的一個項目很類似，把報文送到用戶空間處理，用PF_packet也可以。

用netfilter，使用正確的接口，也不會出現(xiàn)內(nèi)存泄露。

guotie

原帖由 xiaozhaoz 于 2006-1-9 09:53 發(fā)表
樓主的前提是錯誤的，報文的處理過程不一定在軟中斷中進行，即使是接收和ip層處理，請參考NAPI和softirqd代碼。當(dāng)接收報文長時間占用軟中斷后，會啟動softirqd內(nèi)核線程執(zhí)行報文處理。 內(nèi)核2.6.15-rt2

感覺樓主 ...

能仔細講講NAPI，softirq和接受報文的關(guān)系嗎？

guotie

hehe,我對數(shù)據(jù)報直接在內(nèi)核處理，并不把它轉(zhuǎn)移到用戶空間。

所以，不用PF_packet

xiaozhaoz

NAPI的由來：

NAPI是2.4.20后的內(nèi)核版本在網(wǎng)卡驅(qū)動做的一項優(yōu)化措施，當(dāng)年某個商業(yè)測試2.2的Linux和Winnt的網(wǎng)絡(luò)效率，Linux在小包處理吞吐量輸了，這個報告引起了很大的爭議，后來Linux在驅(qū)動采取了一系列的優(yōu)化措施，NAPI是很重要的一個。

NAPI的原理： 一般情況下，每接收到一個幀，都會出發(fā)一次網(wǎng)絡(luò)中斷，然后軟中斷處理這個報文，直到報文到目的地(轉(zhuǎn)發(fā)或用戶socket buffer).
現(xiàn)在的做法，大流量情況下，收中斷是不啟用的。這樣收幀不會頻繁觸發(fā)網(wǎng)絡(luò)中斷，而是報文到了一定數(shù)量后觸發(fā)一次中斷，如8139網(wǎng)卡。在cp_interrupt()中，會調(diào)用NAPI的接口，將網(wǎng)卡加入到softirq任務(wù)鏈表中，然后喚醒softirq， 在softirq中，回調(diào)dev中的接口批量處理報文。

        if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr))
                if (netif_rx_schedule_prep(dev)) {
                        cpw16_f(IntrMask, cp_norx_intr_mask);
                        __netif_rx_schedule(dev);
                }

__netif_rx_schedule() -->
{
        unsigned long flags;

        raw_local_irq_save(flags);
        dev_hold(dev);
/* 將dev加入到軟中斷處理鏈表中 */
        list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
        if (dev->quota < 0)
                dev->quota += dev->weight;
        else
                dev->quota = dev->weight;
/* 喚醒軟中斷 */
        raise_softirq_irqoff(NET_RX_SOFTIRQ);
        raw_local_irq_restore(flags);
}

軟中斷處理中，會利用dev->poll() 函數(shù)，實現(xiàn)一次軟中斷，處理大量報文，如8139
cp_rx_poll() -->
批量處理網(wǎng)卡buffer中的報文。

softirq處理過程也有同樣的優(yōu)化，正常情況下，所有的報文都是在軟中斷中完成，但是當(dāng)軟中斷一直有處理不完的報文，為了提高系統(tǒng)實時行，軟中斷處理完一定數(shù)量的報文后，必須退出，剩余的報文通過喚醒softirqd 內(nèi)核線程來完成。
void ___do_softirq(void) -->
/* 如果處理一輪后，仍然后報文要處理，喚醒softirqd任務(wù)代為處理 */
        if (pending)
                trigger_softirqs();

trigger_softirqs()-->
static void trigger_softirqs(void)
{
        u32 pending = local_softirq_pending();
        int curr = 0;

        while (pending) {
                if (pending & 1)
                                             /* 喚醒softirqd */
                        wakeup_softirqd(curr);
                pending >>= 1;
                curr++;
        }
}

內(nèi)核： 2.6.15-rt2

guotie

非常感謝。

ip_rcv,netfilter的處理鏈都是在softirq中進行的，對嗎？

wheelz

> 現(xiàn)在的做法，大流量情況下，收中斷是不啟用的。
> 這樣收幀不會頻繁觸發(fā)網(wǎng)絡(luò)中斷，而是報文到了一定數(shù)量后觸發(fā)一次中斷

這個說法欠妥，并不是“報文到了一定數(shù)量后觸發(fā)一次中斷”，
而是，只有第一個中斷會觸發(fā)，然后NAPI會關(guān)中斷，進入poll()，持續(xù)收包。

xiaozhaoz

同意你的說法。

to guotie：
ip_rcv,netfilter 不一定都是在軟中斷中進行：
我上面的描述中已經(jīng)說了：
當(dāng)軟中斷持續(xù)被觸發(fā)時，為了保持系統(tǒng)實時行，會將后續(xù)的報文處理放到softirqd任務(wù)中進行，這時一個內(nèi)核任務(wù)，默認情況下，每個CPU啟一個。

所以ip_rcv可能運行在兩種上下文中：
1. 軟中斷 （軟中斷有自己的棧，但是上下文是在被中斷的任務(wù)中）
2. softirqd 內(nèi)核線程

用戶程序報文的發(fā)送是在自己的上下文中完成。

guotie

非常感謝！�。�