Re: RFC: NAPI packet weighting patch

["David S. Miller" <davem@davemloft.net>]

From: jamal <hadi@cyberus.ca>
Date: Fri, 03 Jun 2005 14:42:30 -0400

> When you reduce the weight, the system is spending less time in the
> softirq processing packets before softirq yields. If this gives more
> opportunity to your app to run, then the performance will go up.
> Is this what you are seeing? 

Jamal, this is my current theory as well, we hit the jiffies
check.

It it the only logical explanation I can come up with for the
single adapter case.

There are some ways we can mitigate this.  Here is one idea
off the top of my head.

When the jiffies check is hit, lower the weight of the most recently
polled device towards some minimum (perhaps divide by two).  If we
successfully poll without hitting the jiffies check, make a small
increment of the weight up to some limit.

It is Van Jacobson TCP congestion avoidance applied to NAPI :-)

Just a simple AIMD (Additive Increase, Multiplicative Decrease).
So, hitting the jiffies work limit is congestion, and the cause
of the congestion is the most recently polled device.

In this regime, what the driver currently specifies as "->weight"
is actually the maximum we'll use in the congestion control
algorithm.  And we can choose some constant minimum, something
like "8" ought to work well.

Comments?