netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: nhorman@tuxdriver.com, netdev@vger.kernel.org, fubar@us.ibm.com,
	andy@greyhouse.net
Subject: Re: [PATCH] bonding: reset queue mapping prior to transmission to physical device
Date: Thu, 02 Jun 2011 22:22:09 +0200	[thread overview]
Message-ID: <4DE7F0F1.3010800@gmail.com> (raw)
In-Reply-To: <20110602.130710.1904222486883754792.davem@davemloft.net>

Le 02/06/2011 22:07, David Miller a écrit :
> From: Neil Horman<nhorman@tuxdriver.com>
> Date: Thu,  2 Jun 2011 14:03:19 -0400
>
>> The bonding driver is multiqueue enabled, in which each queue represents a slave
>> to enable optional steering of output frames to given slaves against the default
>> output policy.  However, it needs to reset the skb->queue_mapping prior to
>> queuing to the physical device or the physical slave (if it is multiqueue) could
>> wind up transmitting on an unintended tx queue (one that was reserved for
>> specific traffic classes for instance)
>>
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>
> Since, as I mentioned, the idea when we are forwarding and bridging is that
> we use the input receive classification to influence the spread on transmit,
> I think things like this bonding case should remember the rxhash setting
> before they override it and then restore that value right before invoking
> dev_queue_xmit().

Ok, now I understand. Maybe, using queue mapping for special slave selection wasn't such a good idea 
at the very beginning, because it pollutes the RX mapping that is expected to be propagated up to 
TX. Restoring the original value before invoking dev_queue_xmit() would fix this, but I'm not sure 
it is the cleanest way to do it.

	Nicolas.

  reply	other threads:[~2011-06-02 20:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 18:03 [PATCH] bonding: reset queue mapping prior to transmission to physical device Neil Horman
2011-06-02 18:35 ` Ben Hutchings
2011-06-02 18:56   ` Neil Horman
2011-06-02 19:09     ` Ben Hutchings
2011-06-02 19:46       ` Neil Horman
2011-06-02 19:52         ` Nicolas de Pesloüan
2011-06-02 20:04         ` David Miller
2011-06-02 20:13           ` Nicolas de Pesloüan
2011-06-02 20:46             ` David Miller
2011-06-02 20:51               ` Ben Hutchings
2011-06-02 21:10                 ` David Miller
2011-06-02 20:13         ` Ben Hutchings
2011-06-03  1:16           ` Neil Horman
2011-06-02 19:59   ` David Miller
2011-06-02 20:07 ` David Miller
2011-06-02 20:22   ` Nicolas de Pesloüan [this message]
2011-06-03  1:04   ` Neil Horman
2011-06-03 13:26 ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v2) Neil Horman
2011-06-03 14:43   ` Ben Hutchings
2011-06-03 17:32     ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v3) Neil Horman
2011-06-03 17:59       ` Ben Hutchings
2011-06-03 18:36         ` Neil Horman
2011-06-03 19:12           ` Ben Hutchings
2011-06-03 19:23             ` Neil Horman
2011-06-03 19:24         ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v4) Neil Horman
2011-06-03 19:48           ` Eric Dumazet
2011-06-03 19:57             ` Neil Horman
2011-06-03 20:05               ` Eric Dumazet
2011-06-03 20:35           ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v5) Neil Horman
2011-06-03 23:31             ` Jay Vosburgh
2011-06-05 21:32               ` David Miller
2011-06-03 18:06       ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v3) Jay Vosburgh
2011-06-03 14:59   ` [PATCH] bonding: reset queue mapping prior to transmission to physical device (v2) Vitalii Demianets

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=4DE7F0F1.3010800@gmail.com \
    --to=nicolas.2p.debian@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=fubar@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    /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).