All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitch Williams <mitch.a.williams@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Jeff Moyer <jmoyer@redhat.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
	Matt Mackall <mpm@selenic.com>,
	"Garzik, Jeff" <jgarzik@pobox.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: Mon, 12 Jun 2006 09:42:14 -0700	[thread overview]
Message-ID: <1150130534.2879.9.camel@strongmad> (raw)
In-Reply-To: <20060612001356.GA5112@localhost.localdomain>

On Sun, 2006-06-11 at 17:13 -0700, Neil Horman wrote:
> Any further thoughts on this guys?  I still think my last solution
> solves all of
> the netpoll problems, and isn't going to have any noticable impact on
> performance.
> 
I haven't had time to evaluate performance on your patch (sorry!), but
after thinking about it, I agree that it should not have any noticeable
impact.  OTOH, performance tuning is a funny thing, and things you think
won't cause problems often do.

Anyway, I'm still not quite ready to ACK this because it's just not
future-proof.  Eventually, we will need to support multiple RX queues,
and this solution will not work in that situation.

A simpler short-term solution is just to schedule our NAPI polling on
the "real" netdev instead of our polling netdev.  This is a trivial
change and works correctly with a single queue.  But, like your patch,
it isn't future-proof.

So, I'm still thinking and pondering on this one.

If we get a patch in to fix the recursive loop in netpoll, my original
patch will work, right?  Or is there still another issue?

-Mitch

  reply	other threads:[~2006-06-12 16:42 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
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 [this message]
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=1150130534.2879.9.camel@strongmad \
    --to=mitch.a.williams@intel.com \
    --cc=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=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 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.