From: David Miller <davem@davemloft.net>
To: netdev@vger.kernel.org
Cc: auke-jan.h.kok@intel.com
Subject: NAPI poll behavior in various Intel drivers
Date: Fri, 04 Jan 2008 03:40:36 -0800 (PST) [thread overview]
Message-ID: <20080104.034036.160194618.davem@davemloft.net> (raw)
Several Intel networking drivers such as e1000, e1000e
and e100 all do this to exit NAPI polling:
if ((!tx_cleaned && (work_done == 0)) ||
!netif_running(poll_dev)) {
I tried to make this use in the NAPI rework:
if ((!tx_cleaned && (work_done < budget)) ||
!netif_running(poll_dev)) {
But that got reverted by:
commit f7bbb9098315d712351aba7861a8c9fcf6bf0213
e1000: Fix NAPI state bug when Rx complete
Don't exit polling when we have not yet used our budget, this causes
the NAPI system to end up with a messed up poll list.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
I definitely would not have signed off on that :-)
That "tx_cleaned" thing clouds the logic in all of these driver's
poll routines.
The one necessary precondition is that when work_done < budget
we exit polling and return a value less than budget.
If the ->poll() returns a value less than budget, net_rx_action()
assumes that the device has been removed from the poll() list.
/* Drivers must not modify the NAPI state if they
* consume the entire weight. In such cases this code
* still "owns" the NAPI instance and therefore can
* move the instance around on the list at-will.
*/
if (unlikely(work == weight))
list_move_tail(&n->poll_list, list);
This "work_done == 0" test in these drivers, is thus, wrong. It
should be "work_done < budget" and the whole tx_cleaned thing needs to
be removed.
It happens to work, because what happens is that we loop again and
process the same NAPI struct again.
As a result, E1000 devices get polled TWICE every time they
process at least one RX packet, but do not consume the whole
quota.
I smell a performance hack, and if so this is wrong and against
all of the principles of NAPI. Either that or it's a workaround
for the "!netif_running()" case.
I noticed this while trying to work on a generic fix for the
"->poll() does not exit when device is brought down while being
bombed with packets" bug.
next reply other threads:[~2008-01-04 11:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-04 11:40 David Miller [this message]
2008-01-04 20:10 ` NAPI poll behavior in various Intel drivers James Chapman
2008-01-04 21:24 ` David Miller
2008-01-05 0:18 ` James Chapman
2008-01-05 7:25 ` David Miller
2008-01-05 13:29 ` Andi Kleen
2008-01-06 4:15 ` David Miller
2008-01-07 8:24 ` Jarek Poplawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080104.034036.160194618.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=auke-jan.h.kok@intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).