Thread (33 messages) flat view 33 messages, 7 authors, 2011-06-05

Re: [PATCH] bonding: reset queue mapping prior to transmission to physical device (v5)

From: David Miller <davem@davemloft.net>
Date: 2011-06-05 21:33:46

From: Jay Vosburgh <redacted>
Date: Fri, 03 Jun 2011 16:31:06 -0700
Neil Horman [off-list ref] wrote:
quoted
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

Change Notes:
v2) Based on first pass review, updated the patch to restore the origional queue
mapping that was found in bond_select_queue, rather than simply resetting to
zero.  This preserves the value of queue_mapping when it was set on receive in
the forwarding case which is desireable.

v3) Fixed spelling an casting error in skb->cb

v4) fixed to store raw queue_mapping to avoid double decrement

v5) Eric D requested that ->cb access be wrapped in a macro.
	Shouldn't the change log go below the "---" so it doesn't end up
in the git commit log?
Yes, usually, however in this case Neil's change notes give some
important information about why the patch is implemented the way it
is, especially the notes about "v2" so I left them in the commit
message.
	In any event, I looked for ways into bond_dev_queue_xmit without
first passing through bond_select_queue (lest stale cb[] data intrude),
and I don't see any, so I think this is ok.

Signed-off-by: Jay Vosburgh <redacted>
Applied, thanks everyone.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help