From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: netdev <netdev@vger.kernel.org>,
themann@de.ibm.com, Christoph Raisch <raisch@de.ibm.com>
Subject: new NAPI interface broken
Date: Fri, 7 Sep 2007 11:37:02 +0200 [thread overview]
Message-ID: <200709071137.02801.ossthema@de.ibm.com> (raw)
Hi Stephen,
I saw that you developed most of the new NAPI interface.
I already addressed this issue a while ago. Please correct me if I got
it wrong. I think there is still a serious problem with the NAPI
changes to make NAPI polling independent of struct net_device objects.
Its about the question who inserts and removes devices from the poll list.
netif_rx_schedule: sets NAPI_STATE_SCHED flag, insert device in poll list.
netif_rx_complete: clears NAPI_STATE_SCHED
netif_rx_reschedule: sets NAPI_STATE_SCHED, insert device in poll list.
net_rx_action:
-removes dev from poll list
-calls poll function
-adds dev to poll list if NAPI_STATE_SCHED still set
1) netif_rx_complete and netif_rx_reschedule don't work together
2) On SMP systems: after netif_rx_complete has been called on CPU1
(+interruts enabled), netif_rx_schedule could be called on CPU2
(irq handler) before net_rx_action on CPU1 has checked NAPI_STATE_SCHED.
In that case the device would be added to poll lists of CPU1 and CPU2
as net_rx_action would see NAPI_STATE_SCHED set.
This must not happen. It will be caught when netif_rx_complete is
called the second time (BUG() called)
This would mean we have a problem on all SMP machines right now.
If I got all this right then we probably need a further flag to tell
net_rx_action whether to poll again or to stop (with the possibility
that the device has been scheduled on a different CPU in between).
The "old" NAPI interface uses the return value of poll to determine
if the device has to be polled again or not.
We can either switch back or in case we want to stick to
the new return value, we might have to add something similar to
the NAPI_STATE_SCHED flag or a new parameter...
Regards,
Jan-Bernd
next reply other threads:[~2007-09-07 9:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 9:37 Jan-Bernd Themann [this message]
2007-09-12 12:50 ` new NAPI interface broken David Miller
2007-09-12 13:10 ` new NAPI interface broken for POWER architecture? Christoph Raisch
2007-09-12 13:27 ` David Miller
2007-09-12 15:18 ` Arnd Bergmann
2007-10-16 7:29 ` new NAPI interface broken Benjamin Herrenschmidt
2007-10-16 7:42 ` Benjamin Herrenschmidt
2007-10-16 7:44 ` David Miller
2007-10-16 8:28 ` Benjamin Herrenschmidt
2007-10-16 8:31 ` David Miller
2007-10-16 9:01 ` Benjamin Herrenschmidt
2007-10-16 21:01 ` Anton Blanchard
2007-10-17 15:26 ` Christoph Raisch
2007-10-16 15:56 ` Arjan van de Ven
2007-09-14 22:12 ` David Miller
2007-09-18 16:15 ` Jan-Bernd Themann
2007-09-18 19:08 ` David Miller
2007-09-19 15:33 ` Roland Dreier
2007-09-19 15:43 ` Jan-Bernd Themann
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=200709071137.02801.ossthema@de.ibm.com \
--to=ossthema@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=raisch@de.ibm.com \
--cc=shemminger@linux-foundation.org \
--cc=themann@de.ibm.com \
/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).