Re: Dropping Packets in 2.6.17

[Danial Thom]

--- Robert Hancock <hancockr@xxxxxxx> wrote:

> Danial Thom wrote:
> >>
> >> I didn't use ITR, I used NAPI.
> >>
> > 
> > If thats the case then your "system" would
> have
> > the same problem that I'm encountering, since
> > polling results in buckets of packets being
> > dropped with heavy userland activity.
> 
> This is to some extent by design. If you
> processed all packets purely in 
> interrupt context, at some point you can start
> receiving so many packets 
> that you never leave interrupt context to
> perform any other useful work, 
> no matter if your adapter can avoid generating
> an interrupt for every 
> packet. Packet floods can completely hang the
> machine. Pushing the work 
> into a softirq and disabling NIC interrupts in
> the interim allows the 
> machine to continue performing other useful
> work.

You guys keep talking about generating an int for
every packet, and like no controller designed
after 1998 does it, so why are you still talking
about it?

Yes, this is the "design" thats flawed. Apps like
MySQL and compilers always try to use all of the
cpu, and if it results in the system *thinking*
that its being flooded then its not working
properly. A network stream that is using less
that 20% of the cpu should *never* drop any
packets. 

> If you want to give more priority to processing
> network packets at the 
> expense of user processes then you likely need
> to increase the priority 
> of the ksoftirqd thread(s). These compete for
> CPU time like any other 
> processes.

I've tried this and it doesn't do much in terms
of alleviate the problem. It makes a marginal
difference.

I think much of the problem is that the network
guys are spending so much time on frivilous
things like polling that they have no interest in
getting the hardware to work the way its supposed
to. Ironically, if the harware worked properly
there would be no reason to have polling.

Detecting a livelock condition is easy. There's
no reason to drop packets randomly. Additionally
a workload tunable would deflect the argument
against allowing near-livelock conditions.
Dropping packets should be a last resort; not the
norm.

DT

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/