Messages in this thread | | | Subject | NAPI Race? | Date | 07 Oct 2003 20:07:31 -0700 | From | Marko Rauhamaa <> |
| |
It looks to me like net_rx_action() might suffer from a race, which in turn might explain some weirdness in my driver test results.
Here's the essence of the function from net/core/dev.c:
net_rx_action() { local_irq_disable(); while (!list_empty(&queue->poll_list)) { local_irq_enable(); /* do stuff */ local_irq_disable(); } local_irq_enable(); }
Say I receive a packet. net_rx_action() processes it in the while loop and reenables interrupts. But just before net_rx_action() returns, I receive another packet, and __netif_rx_schedule() gets called from the driver. Then the soft irq is raised from within itself. If I'm not interrupted for some other reason, the packet will get processed only at the next jiffie when the soft irq is invoked again.
Am I mistaken?
As an aside, it looks also as though the design might technically allow the network driver to starve the CPU (the very situation NAPI was designed to protect against). If I receive a new packet always right after returning from net_rx_action(), the interrupt will cause the soft irq to be executed immediately. It's true that this scenario would require a very accurately calibrated packet stream, but in my business that just might take place.
Marko
-- Marko Rauhamaa mailto:marko@pacujo.net http://pacujo.net/marko/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |