NAPI Race?

[Marko Rauhamaa <marko@pacujo.net>]

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/