From: Jay Vosburgh <fubar@us.ibm.com>
To: Andy Gospodarek <andy@greyhouse.net>, Phil Oester <kernel@linuxace.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] bonding: bond_select_queue off by one
Date: Thu, 17 Feb 2011 20:41:48 -0800 [thread overview]
Message-ID: <22094.1298004108@death> (raw)
In-Reply-To: <20110218020713.GA9696@linuxace.com>
Phil Oester <kernel@linuxace.com> wrote:
>The bonding driver's bond_select_queue function simply returns
>skb->queue_mapping. However queue_mapping could be == 16
>for queue #16. This causes the following message to be flooded
>to syslog:
>
>kernel: bondx selects TX queue 16, but real number of TX queues is 16
>
>ndo_select_queue wants a zero-based number, so bonding driver needs
>to subtract one to return the proper queue number. Also fix grammar in
>a comment while in the vicinity.
Andy, can you comment on this?
If memory serves, the omission of queue ID zero was on purpose;
is this patch going to break any of the functionality added by:
commit bb1d912323d5dd50e1079e389f4e964be14f0ae3
Author: Andy Gospodarek <andy@greyhouse.net>
Date: Wed Jun 2 08:40:18 2010 +0000
bonding: allow user-controlled output slave selection
Ben Hutchings <bhutchings@solarflare.com> wrote:
>This looks basically correct, but it should use the proper functions:
>
> skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
As Ben points out, skb_rx_queue_recorded, skb_record_rx_queue,
et al, do the offset by one internally, but the bond_slave_override
function is comparing the slave's queue_id to the skb->queue_mapping.
That makes me wonder if this patch is going to mess things up,
and if bond_slave_override should also use the skb_rx_queue_recorded, et
al, functions.
-J
>Phil Oester
>
>Signed-off-by: Phil Oester <kernel@linuxace.com>
>
>
>--- linux-2.6/drivers/net/bonding/bond_main.c.orig 2011-01-30 09:15:09.813843817 -0800
>+++ linux-2.6/drivers/net/bonding/bond_main.c 2011-02-17 18:02:46.919050909 -0800
>@@ -4537,11 +4537,11 @@
> {
> /*
> * This helper function exists to help dev_pick_tx get the correct
>- * destination queue. Using a helper function skips the a call to
>+ * destination queue. Using a helper function skips a call to
> * skb_tx_hash and will put the skbs in the queue we expect on their
> * way down to the bonding driver.
> */
>- return skb->queue_mapping;
>+ return skb->queue_mapping ? skb->queue_mapping - 1 : 0;
> }
>
> static netdev_tx_t bond_start_xmit(struct sk_buff *skb, struct net_device *dev)
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2011-02-18 4:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 2:07 [PATCH] bonding: bond_select_queue off by one Phil Oester
2011-02-18 3:46 ` Ben Hutchings
2011-02-18 4:41 ` Jay Vosburgh [this message]
2011-02-18 22:49 ` Andy Gospodarek
2011-02-18 23:06 ` Ben Hutchings
2011-02-21 18:06 ` Andy Gospodarek
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=22094.1298004108@death \
--to=fubar@us.ibm.com \
--cc=andy@greyhouse.net \
--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 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.