[Top] [All Lists]

Re: tun.c patch to fix "smp_processor_id() in preemptible code"

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: tun.c patch to fix "smp_processor_id() in preemptible code"
From: Lee Revell <rlrevell@xxxxxxxxxxx>
Date: Tue, 19 Oct 2004 17:51:17 -0400
Cc: vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, Linux Network Development <netdev@xxxxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>
In-reply-to: <E1CK1e6-0004F3-00@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <E1CK1e6-0004F3-00@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 2004-10-19 at 17:35, Herbert Xu wrote:
> Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> > 
> > I looked at Robert Love's book and I am still unclear on the use of
> > do_softirq above.  To reiterate the question:  why does netif_rx_ni have
> > to manually flush any pending softirqs on the current proccessor after
> > doing the rx?  Is this just a performance hack?
> Yes it allows the packet to be processed immediately.

Ok, here is the correct patch.  If this is really just a matter of
performance, and not required for correctness, disabling preemption is
broken, right?


--- include/linux/netdevice.h~  2004-10-15 20:19:33.000000000 -0400
+++ include/linux/netdevice.h   2004-10-19 17:47:03.000000000 -0400
@@ -697,8 +697,6 @@
 static inline int netif_rx_ni(struct sk_buff *skb)
        int err = netif_rx(skb);
-       if (softirq_pending(smp_processor_id()))
-               do_softirq();
        return err;

<Prev in Thread] Current Thread [Next in Thread>