From: Patrick McHardy <kaber@trash•net>
To: Jarek Poplawski <jarkao2@gmail•com>
Cc: 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: Thu, 29 Oct 2009 17:37:23 +0100 [thread overview]
Message-ID: <4AE9C4C3.9040503@trash.net> (raw)
In-Reply-To: <20091028212337.GA3218@ami.dom.local>
Jarek Poplawski wrote:
> On Wed, Oct 28, 2009 at 06:27:10PM +0100, Patrick McHardy wrote:
>> We don't seem to be supporting changing real_num_tx_queues for
>> registered devices currently (at least I couldn't find it).
>> So I guess it depends on how this would be implemented.
>>
>> Simply changing the dev->real_num_tx_queues value while the
>> device is down would require qdisc operations to operate on
>> all possible queues since the amount of queues in use could
>> be changed after the qdisc is created/configured, but before
>> the device is set up. This approach has more complications
>> like switching between mq and non-mq root qdiscs, taking care
>> of non-default root qdisc (cloning them to the new queues), etc.
>>
>> A simpler alternative would be to destroy the existing root
>> qdisc on any change to real_num_tx_queues and have dev_activate()
>> set it up from scratch. In this case, we could (as you suggested)
>> use real_num_tx_queues, which should fix the problem Eric reported.
>
> Actually, I changed my mind after Eric's and especially David's
> explanations. Probably there will be needed some changes in handling
> the real_num_tx_queues, but there is no reason to misuse them for
> masking a totally useless num_tx_queues value, like in this case. So,
> IMHO, its mainly about the driver(s) (and maybe a bit of API change)
> here.
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.
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.
next prev parent reply other threads:[~2009-10-29 16:37 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 [this message]
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
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=4AE9C4C3.9040503@trash.net \
--to=kaber@trash$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=jarkao2@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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