[Top] [All Lists]

Re: More questions...

To: andrewm@xxxxxxxxxx (Andrew Morton)
Subject: Re: More questions...
From: kuznet@xxxxxxxxxxxxx
Date: Mon, 3 Apr 2000 19:42:22 +0400 (MSK DST)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <38E88597.D6F4FF94@xxxxxxxxxx> from "Andrew Morton" at Apr 3, 0 11:50:47 am
Sender: owner-netdev@xxxxxxxxxxx

> You miss my point.
> /* Use this variant when it is known for sure that it
>  * is executing from interrupt context.
>  */
> extern __inline__ void dev_kfree_skb_irq(struct sk_buff *skb)
> {
>         if (atomic_dec_and_test(&skb->users)) {
>                 int cpu =smp_processor_id();
>                 unsigned long flags;
>                 local_irq_save(flags);
>                 skb->next = softnet_data[cpu].completion_queue;
>                 softnet_data[cpu].completion_queue = skb;
>                 __cpu_raise_softirq(cpu, NET_TX_SOFTIRQ);
>                 local_irq_restore(flags);
>         }
> }
> If "it is known for sure" then why does this function need the
> local_irq_save()?

No, I understood you. (I repeat) There is no single serialized
"interrupt context". When telling "interrupt context", we say really:
"from the worst possible context, totally unserialized"

The recommendation "for sure" stands there, because this function
is pure overhead, when called from BH or process context.
Besides that it can result in too long delay until real packet
destruction and sockets can starve of write skbs.

> Is it because this CPU could take an interrupt for a different device
> and, within the nested ISR, find its completion queue in an inconsistent
> state?

Yes, exactly.


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