From: Ben Hutchings <bhutchings@solarflare.com>
To: David Miller <davem@davemloft.net>
Cc: kernel@linuxace.com, andy@greyhouse.net, netdev@vger.kernel.org,
fubar@us.ibm.com
Subject: Re: [PATCH 1/2] bonding: fix incorrect transmit queue offset
Date: Wed, 23 Feb 2011 23:37:49 +0000 [thread overview]
Message-ID: <1298504269.2211.503.camel@localhost> (raw)
In-Reply-To: <20110223.151357.245408084.davem@davemloft.net>
On Wed, 2011-02-23 at 15:13 -0800, David Miller wrote:
> From: Phil Oester <kernel@linuxace.com>
> Date: Wed, 23 Feb 2011 15:08:44 -0800
>
> > On Wed, Feb 23, 2011 at 02:42:49PM -0500, Andy Gospodarek wrote:
> >> + * destination queue. Using a helper function skips the a call to
> >
> > s/the a/a/ or s/the a/the/
> >
> >> + while (txq >= dev->real_num_tx_queues) {
> >> + /* let the user know if we do not have enough tx queues */
> >> + if (net_ratelimit())
> >> + pr_warning("%s selects invalid tx queue %d. Consider"
> >> + " setting module option tx_queues > %d.",
> >> + dev->name, txq, dev->real_num_tx_queues);
> >> + txq -= dev->real_num_tx_queues;
> >> + }
> >
> > Think this would be better as a WARN_ONCE, as otherwise syslog will still
> > get flooded with this - even when ratelimited. See get_rps_cpu in
> > net/core/dev.c as an example.o
>
> Agreed.
This shouldn't WARN at all. It is perfectly valid (though non-optimal)
to have different numbers of queues on two different multiqueue devices.
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.
next prev parent reply other threads:[~2011-02-23 23:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 19:42 [PATCH 1/2] bonding: fix incorrect transmit queue offset Andy Gospodarek
2011-02-23 22:19 ` Jay Vosburgh
2011-02-23 23:12 ` Andy Gospodarek
2011-02-23 23:08 ` Phil Oester
2011-02-23 23:13 ` David Miller
2011-02-23 23:37 ` Ben Hutchings [this message]
2011-02-23 23:43 ` Andy Gospodarek
2011-02-23 23:54 ` David Miller
2011-02-25 22:56 ` Phil Oester
2011-03-01 15:31 ` [PATCH 1/2 net-next][v2] " Andy Gospodarek
2011-03-02 1:40 ` Phil Oester
2011-03-04 17:37 ` Jay Vosburgh
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=1298504269.2211.503.camel@localhost \
--to=bhutchings@solarflare.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=kernel@linuxace.com \
--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).