Hi,
On 10-2-26 下午9:17, Dirk Vogt wrote:
Hi,
the DDE models a SMP-like setup, whereas each ddekit_thread is supposed to run on a dedicated CPU. For each IRQ, there is a dedicated ddekit_thread. As far as I understand it, disabling hard IRQs in any other ddekit_thread than the IRQ-handler threads has no effect, because they won't receive IRQs anyway. For an IRQ handler thread, it also has no effect, because it only runs when it is handling an interrupt, and won't receive any further IRQs while handling one.
I was talking about synchronization between hard IRQ handler and softirq handler.
When the driver receives a hard IRQ, it tries to raise softirq. local_irq_save(flags); list_add_tail(&n->poll_list, &__get_cpu_var(softnet_data).poll_list); __raise_softirq_irqoff(NET_RX_SOFTIRQ); local_irq_restore(flags); The softirq thread, on the other hand, does local_irq_save(flags); if (local_softirq_pending()) __do_softirq(); local_irq_restore(flags); In __do_softirq, it does unsigned long pending = local_softirq_pending();
/* reset softirq count */ set_softirq_pending(0);
In Linux local_irq_save() disables irqs in the local processor, so if the hard IRQ handler tries to raise softirq, it is guaranteed that the softirq thread will not be scheduled to run, and vice versa. Since DDE doesn't disable IRQs in the local processor, there is a possibility that __do_softirq gets the pending softirq and then the cpu schedules to run the hard IRQ interrupt, which raise a softirq, and then the cpu is scheduled to run the softirq thread again and runs set_softirq_pending(0). The raised irq is just lost.
Unless I am mistaken, I think it is what causes my problem.
Best regards, Zheng Da