From: Ben Hutchings <bhutchings@solarflare.com>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Cc: David Miller <davem@davemloft.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"bphilips@novell.com" <bphilips@novell.com>,
shemminger@linux-foundation.org
Subject: Re: [net-next-2.6 RFC PATCH] e1000e: NUMA changes, add Node= parameter
Date: Thu, 23 Sep 2010 18:17:24 +0100 [thread overview]
Message-ID: <1285262244.7794.11.camel@achroite.uk.solarflarecom.com> (raw)
In-Reply-To: <alpine.WNT.2.00.1009230932300.5948@jbrandeb-desk1.amr.corp.intel.com>
On Thu, 2010-09-23 at 09:46 -0700, Brandeburg, Jesse wrote:
>
> On Wed, 22 Sep 2010, David Miller wrote:
>
> > From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Date: Wed, 22 Sep 2010 20:28:10 -0700
> >
> > > Although a module parameter is not the preferred way for
> > > in-tree modules, this problem is not solvable in ethtool without
> > > mod params because of needing the information at probe time to
> > > control early allocations of memory. Ideally there would even be
> > > a way to control the node where the memory of the netdev struct
> > > would be allocated also.
> >
> > Sorry, no.
> >
> > Various folks are working on infrastructure such that the Numa node of
> > everything other than the netdev struct can be dynamically choosen.
> >
> > I'm sure we can find a way to dynamically reallocate and re-attach the
> > netdev structure as well.
>
> okay, thanks for your comments, we can carry this patch out-of-tree.
>
> Unfortunately as I said in the comments there is really no way around this
> *now* other than some fixed binding scheme, none of which are one size
> fits all, which is why I (reluctantly) supplied the module parameter
> patch.
>
> I'm interested to hear more about the "various folks' infrastructure"
> plans, I'll do some research. I can definitely provide testing.
[...]
I think David may be referring to this:
http://article.gmane.org/gmane.linux.network/172386
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
prev parent reply other threads:[~2010-09-23 17:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 3:28 [net-next-2.6 RFC PATCH] e1000e: NUMA changes, add Node= parameter Jeff Kirsher
2010-09-23 3:36 ` David Miller
2010-09-23 16:46 ` Brandeburg, Jesse
2010-09-23 17:17 ` Ben Hutchings [this message]
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=1285262244.7794.11.camel@achroite.uk.solarflarecom.com \
--to=bhutchings@solarflare.com \
--cc=bphilips@novell.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--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.