lkml.org 
[lkml]   [2003]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: NAPI Race?
Date
From
kuznet@ms2.inr.ac.ru:

> > 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?
>
> Yes, you are wrong. It is processed as soon as possible.

If I receive a packet at the tail end of net_rx_action(), we will
schedule the softirq again. But do_softirq() explicitly refuses to run
the same softirq right away. The softirq will be invoked at the next
interrupt, timer tick, system call (?) or when ksoftirqd is scheduled.
It may happen that none of these events occur for milliseconds.

> > 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).
>
> Nope. NAPI is not expected to cure starvation caused by softirqs.

Well, it almost does. You can blast a NAPI driver with a packet flood,
and the system is happy and responsive -- no interrupts are generated,
and packets are polled by ksoftirqd. However, you can find a packet rate
that will cause the CPU to spend virtually all of its time in NAPI.


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.061 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site