lkml.org 
[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectNAPI Race?
Date
From

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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.041 / U:0.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site