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

guotie

軟中斷  和 ksoftirqd 內(nèi)核線程  是不可以相互搶占的吧？

albcamus

ksoftirqd就算運行在process context了， 只有普通內(nèi)核線程的優(yōu)先級， 不如中斷上下文的softirq。
我覺得很有可能某個softirq(say A)被重復觸發(fā)，于是ksoftirqd開始運行， 正好被某個設備中斷，中斷返回時執(zhí)行該ISR中raise了的softirq，執(zhí)行完畢才回到ksofirqd（還有可能不回去，而是被搶占）。

BTW guotie兄，這個帖子有wheelz和xiaozhaoz二位的精彩論述，針對NAPI和報文接受， 我改下題目加個精華好么

guotie

同意。

感謝斑竹的辛苦勞動！

向您致敬！

思一克

To xiaozhaoz,

我覺得ip_rcv 僅僅是被軟中斷函數(shù)（do_softirq )間接調(diào)用，不被其它調(diào)用。
是net_rx_action　被do_softirq() 調(diào)用，net_rx_action再調(diào)用ip_rcv.
可以找出net_rx_action不被do_softirq調(diào)用的case嗎？

而軟中斷do_softirq()的調(diào)用分為２種情況。
1)被硬中斷調(diào)用（無context, 無自己stack, 一個函數(shù)而已)
2)被kernel thread softirqd調(diào)用，有自己stack. 獨立的context.

大部分情況下1)為真（上次你追問我過次問題，不是僅僅一種情況）。軟中斷忙不過來時才會有2)

do_softirq()在處理過程中可以有新中斷發(fā)生，但do_softirq不會被重入。

我還在看，結論比較齊備后會專門寫個帖子或放到blog.

歡迎討論。

原帖由 xiaozhaoz 于 2006-1-9 12:13 發(fā)表
同意你的說法。

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

guotie

而軟中斷do_softirq()的調(diào)用分為２種情況。
1)被硬中斷調(diào)用（無context, 無自己stack, 一個函數(shù)而已)
2)被kernel thread softirqd調(diào)用，有自己stack. 獨立的context.


我覺得，第一個說法“被硬中斷調(diào)用”似乎不妥，軟中斷的原理決定了它不應該是被調(diào)用的，本質上只是在CPU的soft_vec結構上置位，由cpu檢查到時執(zhí)行。

思一克

1)當有包進入網(wǎng)卡,引起中斷,其調(diào)用TREE如下:

stack c03cc000 trace: tcp_v4_rcv | ip_local_deliver_finish | nf_hook_slow | ip_local_deliver | ip_rcv | netif_receive_skb | process_backlog | net_rx_action | do_softirq | do_IRQ | common_interrupt | cpu_idle

看我上一個帖子

guotie

這個我知道。
net_rx_action | do_softirq | do_IRQ |
有沒有可能是這樣的呢：
net_rx_action | do some timer or tasklet | do_softirq | do_IRQ |

思一克

這個調(diào)用關系不是自己想象的，而是實際trace的結果。
你看do_softirq代碼，會有你說的情況嗎。

guotie

函數(shù)源碼如下（kernel/softirq.c）：
asmlinkage void do_softirq()
{
int cpu = smp_processor_id();
__u32 active, mask;

if (in_interrupt())
return;

local_bh_disable();

local_irq_disable();
mask = softirq_mask(cpu);
active = softirq_active(cpu) & mask;

if (active) {
struct softirq_action *h;

restart:
/* Reset active bitmask before enabling irqs */
softirq_active(cpu) &= ~active;

local_irq_enable();

h = softirq_vec;
mask &= ~active;

do {
if (active & 1)
h->action(h);
h++;
active >>= 1;
} while (active);

local_irq_disable();

active = softirq_active(cpu);
if ((active &= mask) != 0)
goto retry;
}

local_bh_enable();

/* Leave with locally disabled hard irqs. It is critical to close
* window for infinite recursion, while we help local bh count,
* it protected us. Now we are defenceless.
*/
return;

retry:
goto restart;
}
結合上述源碼，我們可以看出軟中斷服務的執(zhí)行過程如下：
（1）調(diào)用宏in_interrupt()來檢測當前CPU此次是否已經(jīng)處于中斷服務中。該宏定義在hardirq.h，請參見5.7節(jié)。
（2）調(diào)用local_bh_disable()宏將當前CPU的中斷統(tǒng)計信息結構中的__local_bh_count成員變量加1，表示當前CPU已經(jīng)處在軟中斷服務狀態(tài)。
（3）由于接下來要讀寫當前CPU的中斷統(tǒng)計信息結構中的__softirq_active變量和__softirq_mask變量，因此為了保證這一個操作過程的原子性，先用local_irq_disable()宏（實際上就是cli指令）關閉當前CPU的中斷。
（4）然后，讀當前CPU的__softirq_active變量值和__softirq_mask變量值。當某個軟中斷向量被觸發(fā)時（即 __softirq_active變量中的相應位被置1），只有__softirq_mask變量中的相應位也為1時，它的軟中斷服務函數(shù)才能得到執(zhí)行。因此，需要將__softirq_active變量和__softirq_mask變量作一次“與”邏輯操作。
（5）如果active變量非 0，說明需要執(zhí)行軟中斷服務函數(shù)。因此：①先將當前CPU的__softirq_active中的相應位清零，然后用local_irq_enable ()宏（實際上就是sti指令）打開當前CPU的中斷。②將局部變量mask中的相應位清零，其目的是：讓do_softirq()函數(shù)的這一次執(zhí)行不對同一個軟中斷向量上的再次軟中斷請求進行服務，而是將它留待下一次do_softirq()執(zhí)行時去服務，從而使do_sottirq()函數(shù)避免陷入無休止的軟中斷服務中。③用一個do{}while循環(huán)來根據(jù)active的值去執(zhí)行相應的軟中斷服務函數(shù)。④由于接下來又要檢測當前CPU的 __softirq_active變量，因此再一次調(diào)用local_irq_disable()宏關閉當前CPU的中斷。⑤讀取當前CPU的 __softirq_active變量的值，并將它與局部變量mask進行與操作，以看看是否又有其他軟中斷服務被觸發(fā)了（比如前面所說的那種情形）。如果有的話，那就跳轉到entry程序段（實際上是跳轉到restart程序段）重新執(zhí)行軟中斷服務。如果沒有的話，那么此次軟中斷服務過程就宣告結束。
（6）最后，通過local_bh_enable()宏將當前CPU的__local_bh_count變量值減1，表示當前CPU已經(jīng)離開軟中斷服務狀態(tài)。宏local_bh_enable()也定義在include/asm-i386/softirq.h頭文件中。

guotie

http://mechgouki.blogdriver.com/mechgouki/282365.html

別人對softirq的分析。