All of lore.kernel.org
 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 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.