netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: Matt Mackall <mpm@selenic.com>, "Garzik, Jeff" <jgarzik@pobox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Jeff Moyer <jmoyer@redhat.com>,
	Mitch Williams <mitch.a.williams@intel.com>,
	netdev@vger.kernel.org, "Brandeburg,
	Jesse" <jesse.brandeburg@intel.com>,
	"Kok, Auke" <auke@foo-projects.org>
Subject: Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Date: Wed, 07 Jun 2006 11:25:29 -0700	[thread overview]
Message-ID: <44871A19.7080805@intel.com> (raw)
In-Reply-To: <20060607164801.GX24227@waste.org>

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Matt Mackall wrote:
> On Wed, Jun 07, 2006 at 11:05:22AM -0400, Neil Horman wrote:
>>>  
>>>> Matt, any ideas on this?
>>> Not at the moment.
>> how about this for a solution?  It doesn't make netpoll any more robust, but I
>> think in the interests of efficiency it would be fair to require that, when
>> netpolled, a driver must receive frames on the same net device for which it was
>> polled.  With this patch we detect that condition and handle it accordingly in
>> e1000_intr.  This eliminates the need for us to call the clean_rx method from
>> the poll_controller when napi is configured, instead allowing the poll method to
>> be called from napi_poll, as the netpoll model currently does.  This fixes the
>> netdump regression, and eliminates the layering violation and the potential race
>> that we've been discussing.  I've just tested it with netdump here and it works
>> quite well.
>>
>> Thoughts appreciated.
> 
> This looks pretty reasonable, mostly from the perspective that it
> doesn't put any further ugliness in netpoll. We might want to add a
> comment somewhere in netpoll of the new rule we're now observing.
> I'll let the e1000 guys comment on the particulars of the driver change.

Hi,

we're not too happy with this as it puts a branch right in the regular receive 
path. We haven't ran the numbers on it yet but it is likely that this will 
lower performance significantly during normal receives for something that is 
not common use.

Attached below a (revised) patch that adds proper locking around the rx_clean 
to prevent the race.

Cheers,

Auke

---

e1000: fix netpoll with NAPI

This fixes netpoll when using NAPI, and protects against a rare race condition
in the netpoll routine, while staying out of our ways from the normal hotpath.

Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>

---
  e1000_main.c |   17 ++++++++++++++++-
  1 file changed, 16 insertions(+), 1 deletion(-)


[-- Attachment #2: e1000_netpoll_napi-r2.patch --]
[-- Type: text/x-patch, Size: 1035 bytes --]

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index bd709e5..876251c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4584,10 +4584,25 @@ static void
 e1000_netpoll(struct net_device *netdev)
 {
 	struct e1000_adapter *adapter = netdev_priv(netdev);
+#ifdef CONFIG_E1000_NAPI
+	int budget = 0;
+
+	disable_irq(adapter->pdev->irq);
+	if (likely(netif_rx_schedule_prep(&adapter->polling_netdev[0]))) {
+		if (spin_trylock(&adapter->tx_queue_lock)) {
+			e1000_clean_tx_irq(adapter, &adapter->tx_ring[0]);
+			spin_unlock(&adapter->tx_queue_lock);
+		}
+		adapter->clean_rx(adapter, adapter->rx_ring,
+				&budget, netdev->weight);
+		clear_bit(__LINK_STATE_RX_SCHED,
+				&adapter->polling_netdev[0].state);
+	}
+#else
+
 	disable_irq(adapter->pdev->irq);
 	e1000_intr(adapter->pdev->irq, netdev, NULL);
 	e1000_clean_tx_irq(adapter, adapter->tx_ring);
-#ifndef CONFIG_E1000_NAPI
 	adapter->clean_rx(adapter, adapter->rx_ring);
 #endif
 	enable_irq(adapter->pdev->irq);

  reply	other threads:[~2006-06-07 18:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-05 23:09 [PATCH 0/2] e1000: fixes for netpoll+NAPI, ARM Kok, Auke
2006-06-05 23:11 ` [PATCH 1/2] e1000: fix netpoll with NAPI Kok, Auke
2006-06-06 13:52   ` Neil Horman
2006-06-06 16:39     ` Mitch Williams
2006-06-06 17:05       ` Neil Horman
2006-06-06 17:18         ` Auke Kok
2006-06-06 17:30           ` Jeff Moyer
2006-06-06 17:34             ` Auke Kok
2006-06-06 17:42               ` Jeff Moyer
2006-06-06 23:17                 ` Matt Mackall
2006-06-07 15:05                   ` Neil Horman
2006-06-07 16:48                     ` Matt Mackall
2006-06-07 18:25                       ` Auke Kok [this message]
2006-06-07 18:44                         ` Jeff Moyer
2006-06-07 19:18                           ` Neil Horman
2006-06-08 17:19                           ` Mitch Williams
2006-06-08 17:29                             ` Jeff Moyer
2006-06-12  0:13                               ` Neil Horman
2006-06-12 16:42                                 ` Mitch Williams
2006-06-12 18:06                                   ` Neil Horman
2006-06-14 20:41                                     ` Neil Horman
2006-06-14 23:44                                       ` Mitch Williams
2006-06-15 12:44                                         ` John W. Linville
2006-06-15 20:45                                           ` Mitch Williams
2006-06-20  8:28                                             ` Andrew Grover
2006-06-07 18:54                         ` John W. Linville
2006-06-08 17:23                           ` Mitch Williams
2006-06-08 18:39                             ` John W. Linville
2006-06-06 17:29       ` Jeff Moyer
2006-06-05 23:11 ` [PATCH 2/2] e1000: remove risky prefetch on next_skb->data Kok, Auke
2006-06-05 23:21   ` Rick Jones
2006-06-06  0:12     ` Brandeburg, Jesse
2006-06-06  0:16       ` Rick Jones
2006-06-06  0:22         ` Andi Kleen
2006-06-06  0:26         ` Brandeburg, Jesse

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=44871A19.7080805@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=auke@foo-projects.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=jmoyer@redhat.com \
    --cc=mitch.a.williams@intel.com \
    --cc=mpm@selenic.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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).