From: Jarek Poplawski <jarkao2@gmail.com>
To: "Kok, Auke" <auke-jan.h.kok@intel.com>
Cc: David Miller <davem@davemloft.net>,
gallatin@myri.com, joonwpark81@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jgarzik@pobox.com,
shemminger@linux-foundation.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [RFC] net: napi fix
Date: Thu, 13 Dec 2007 14:49:53 +0100 [thread overview]
Message-ID: <20071213134953.GA3806@ff.dom.local> (raw)
In-Reply-To: <47602B77.2090202@intel.com>
On 12-12-2007 19:41, Kok, Auke wrote:
> David Miller wrote:
>> From: Andrew Gallatin <gallatin@myri.com>
>> Date: Wed, 12 Dec 2007 12:29:23 -0500
>>
>>> Is the netif_running() check even required?
>> No, it is not.
>>
>> When a device is brought down, one of the first things
>> that happens is that we wait for all pending NAPI polls
>> to complete, then block any new polls from starting.
>
> I think this was previously (pre-2.6.24) not the case, which is why e1000 et al
> has this check as well and that's exactly what is causing most of the
> net_rx_action oopses in the first place. Without the netif_running() check
> previously the drivers were just unusable with NAPI and prone to many races with
> down (i.e. touching some ethtool ioctl which wants to do a reset while routing
> small packets at high numbers). that's why we added the netif_running() check in
> the first place :)
>
> There might be more drivers lurking that need this change...
>
As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
I wonder what is the main reason or gain of leaving such a tricky
exception, instead of letting drivers to always decide which is the
best moment for napi_complete()? (Or maybe even, in such a case, they
should call some function with this list_move_tail() if it's so
useful?)
Regards,
Jarek P.
next prev parent reply other threads:[~2007-12-13 13:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-12 17:29 [RFC] net: napi fix Andrew Gallatin
2007-12-12 17:38 ` David Miller
2007-12-12 17:40 ` Andrew Gallatin
2007-12-12 18:41 ` Kok, Auke
2007-12-13 7:41 ` Joonwoo Park
2007-12-13 14:13 ` Andrew Gallatin
2007-12-13 14:19 ` David Miller
2007-12-13 16:45 ` Kok, Auke
2007-12-13 18:22 ` Stephen Hemminger
2007-12-13 19:02 ` Andrew Gallatin
2007-12-13 19:09 ` David Miller
2007-12-13 19:35 ` Stephen Hemminger
2007-12-13 20:38 ` David Miller
2007-12-14 2:06 ` Joonwoo Park
2007-12-13 13:49 ` Jarek Poplawski [this message]
2007-12-13 13:50 ` David Miller
2007-12-13 14:14 ` Jarek Poplawski
2007-12-13 20:16 ` Jarek Poplawski
2007-12-13 20:37 ` David Miller
2007-12-13 20:41 ` Stephen Hemminger
2007-12-13 21:55 ` Jarek Poplawski
2007-12-13 22:28 ` Jarek Poplawski
2007-12-13 22:34 ` David Miller
2007-12-13 22:58 ` Jarek Poplawski
2007-12-20 9:52 ` Robert Olsson
2007-12-20 11:22 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2007-12-12 4:01 [PATCH 6/7] [NETDEV]: tehuti Fix possible causing oops of net_rx_action Joonwoo Park
2007-12-12 5:39 ` Stephen Hemminger
2007-12-12 5:46 ` [RFC] net: napi fix Stephen Hemminger
2007-12-12 6:05 ` Joonwoo Park
2007-12-12 15:22 ` David Miller
2007-12-12 15:21 ` David Miller
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=20071213134953.GA3806@ff.dom.local \
--to=jarkao2@gmail.com \
--cc=auke-jan.h.kok@intel.com \
--cc=davem@davemloft.net \
--cc=gallatin@myri.com \
--cc=jesse.brandeburg@intel.com \
--cc=jgarzik@pobox.com \
--cc=joonwpark81@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.