From: "Michael Chan" <mchan@broadcom.com>
To: "Jarek Poplawski" <jarkao2@gmail.com>
Cc: "Patrick McHardy" <kaber@trash.net>,
"Eric Dumazet" <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Linux Netdev List" <netdev@vger.kernel.org>
Subject: Re: [RFC] multiqueue changes
Date: Sat, 31 Oct 2009 10:25:52 -0700 [thread overview]
Message-ID: <1257009952.9706.30.camel@HP1> (raw)
In-Reply-To: <20091030100033.GA6150@ff.dom.local>
On Fri, 2009-10-30 at 03:00 -0700, Jarek Poplawski wrote:
> On Thu, Oct 29, 2009 at 11:12:39PM +0100, Patrick McHardy wrote:
> > Jarek Poplawski wrote:
> > > On Thu, Oct 29, 2009 at 05:37:23PM +0100, Patrick McHardy wrote:
> > > ...
> > >> Well, we do need both values for supporting changes to the actually
> > >> used numbers of TX queues. If I understood Dave's explanation correctly,
> > >> this is also what's intended. It also doesn't seem unreasonable
> > >> what bnx2 is doing.
> > >
> > > Exactly. With a growing number of cores, both available and powered
> > > off, these values will be soon treated more carefully than now.
> > >
> > >> But getting back to the problem Eric reported - so you're suggesting
> > >> that bnx2.c should also adjust num_tx_queues in case the hardware
> > >> doesn't support multiqueue? That seems reasonable as well.
> > >
> > > Currently, declaring num_tx_queues with alloc_netdev_mq() looks like
> > > too soon for some drivers. It seems they should be able to do it
> > > separately later during the .probe.
> >
> > The value passed into alloc_netdev_mq() is just used for allocation
> > purposes, from what I can tell there's no downside in reducing it
> > before the dev_activate() call.
>
> Right, but IMHO this reducing (or reallocation) should be done with
> some API. Simple overwriting of num_tx_queues proposed by Eric, even
> if no downside now, seems to be asking for problems in the future.
>
> > > There is a question if .ndo_open should be considered too.
> >
> > I currently can't see any purpose in decreasing num_tx_queues after
> > registration instead of real_num_tx_queues.
>
> I agree, but since Eric's example shows some drivers do it (almost)
> like this, I'd prefer authors/maintainers answer this question.
>
We need the netdev and the private structure at the beginning of
->probe() to store values as we probe the device. Later on in
->probe(), we'll know whether the device supports MSI-X and multiqueue.
If we successfully enable MSI-X in ->ndo_open(), tx multiqueue will be
used.
So if we can separate the allocation of the netdev and the private
structure from the tx queues, we can allocate and set the exact number
of num_tx_queues in ->ndo_open().
next prev parent reply other threads:[~2009-10-31 17:35 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-08 7:18 [RFC] multiqueue changes Eric Dumazet
2009-10-08 9:03 ` Jarek Poplawski
2009-10-08 12:00 ` Jarek Poplawski
2009-10-08 12:13 ` Eric Dumazet
2009-10-08 12:53 ` Jarek Poplawski
2009-10-09 7:58 ` David Miller
2009-10-28 17:27 ` Patrick McHardy
2009-10-28 21:23 ` Jarek Poplawski
2009-10-29 16:37 ` Patrick McHardy
2009-10-29 21:15 ` Jarek Poplawski
2009-10-29 22:12 ` Patrick McHardy
2009-10-30 10:00 ` Jarek Poplawski
2009-10-31 17:25 ` Michael Chan [this message]
2009-11-01 13:20 ` Jarek Poplawski
2009-11-02 11:35 ` David Miller
2009-11-02 12:30 ` Jarek Poplawski
2009-11-02 12:39 ` David Miller
2009-11-02 13:02 ` Jarek Poplawski
2009-11-02 13:03 ` Eric Dumazet
2009-11-02 13:09 ` Jarek Poplawski
2009-12-03 14:10 ` [PATCH] net: Introduce realloc_netdev_mq() Jarek Poplawski
2009-12-03 14:39 ` [PATCH v2] " Jarek Poplawski
2009-12-03 15:17 ` Eric Dumazet
2009-12-03 16:36 ` Jarek Poplawski
2009-12-03 16:54 ` Jarek Poplawski
2009-12-03 17:05 ` Eric Dumazet
2009-12-03 19:04 ` [PATCH v3] " Jarek Poplawski
2009-12-03 20:29 ` [PATCH v4] " Jarek Poplawski
2009-12-03 21:29 ` Eric Dumazet
2009-12-03 21:31 ` David Miller
2009-12-03 21:32 ` Eric Dumazet
2009-12-03 21:51 ` Eric Dumazet
2009-12-03 22:47 ` Jarek Poplawski
2009-12-03 23:04 ` Eric Dumazet
2009-12-04 7:48 ` Jarek Poplawski
2009-12-04 10:51 ` Peter P Waskiewicz Jr
2009-12-04 11:41 ` Jarek Poplawski
2009-12-04 13:01 ` Jarek Poplawski
2009-12-04 13:49 ` Jarek Poplawski
2010-01-16 22:50 ` Michael Chan
2010-01-17 0:36 ` Jarek Poplawski
2010-01-17 16:56 ` Michael Chan
2010-01-17 22:57 ` Jarek Poplawski
2010-01-18 18:29 ` Michael Chan
2010-01-18 19:41 ` Jarek Poplawski
2009-10-09 8:51 ` [RFC] multiqueue changes Jarek Poplawski
2009-10-09 9:40 ` Jarek Poplawski
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=1257009952.9706.30.camel@HP1 \
--to=mchan@broadcom.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jarkao2@gmail.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.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 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).