Message-ID: <12061.1269301015@death.nxdomain.ibm.com>
Date:	Mon, 22 Mar 2010 16:36:55 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Matt Mackall <mpm@...enic.com>
cc:	Amerigo Wang <amwang@...hat.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
	Andy Gospodarek <gospo@...hat.com>,
	Neil Horman <nhorman@...driver.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	bonding-devel@...ts.sourceforge.net,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC Patch 3/3] bonding: make bonding support netpoll

Matt Mackall <mpm@...enic.com> wrote:

>On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> Based on Andy's work, but I modify a lot.
>> 
>> Similar to the patch for bridge, this patch does:
>> 
>> 1) implement the 4 methods to support netpoll for bonding;
>> 
>> 2) modify netpoll during forwarding packets in bonding;
>> 
>> 3) disable netpoll support of bridge when a netpoll-unabled device
>>    is added to bonding;
>> 
>> 4) enable netpoll support when all underlying devices support netpoll.
>
>Again, not sure if this is the right policy. Seems to me that on a
>bonding device we should simply pick an interface to send netpoll
>messages on, without reference to balancing, etc. Thus, if any of the
>bonded devices supports polling, it should work.

	For some of the modes, the above is pretty straighforward.
Others, 802.3ad and balance-alb, are a bit more complicated.

	The risk is that the network peers and switches may see the same
MAC address on multiple ports, or different MAC addresses for the same
IP address.

	To implement the above suggestion, I think a "current netpoll
slave" would have to be tracked, and kept up to date (as slaves become
active or inactive, etc).  Reusing the existing "current active slave"
won't work for the case that the active slave is not netpoll-capable,
but a different slave is; also, not all modes use the current active
slave.

	In 802.3ad, the "current netpoll slave" selector will have to
poke into the aggregator status to choose the netpoll slave.  It's not a
simple matter of picking one and then sticking with it forever; if the
aggregator containing the netpoll slave is deactivated, then peers may
not receive the traffic, etc.

	In the active-backup mode, only the active slave can send or
receive, so if it's not netpoll capable, but a backup slave is, you're
still out of luck (unless netpoll awareness is added to the "best slave"
selection logic, and even then it'd have to be a secondary criteria).
Or, the inactive slave can be transmitted on, but if the same MAC comes
out of the active and a backup slave, it can confuse switches.

	In one mode (balance-alb), slaves keep their own MAC addresses,
and are matched with peers.  Bypassing the balance algorithm could again
confuse peers or switches, who could see two MAC addresses for the same
IP address, if netpoll traffic goes out a different slave than the
balance algorithm picks for the same destination.

	I think, then, the question becomes: is this extra complexity
worth it to cover the cases of netpoll over bonding wherein one or more
slaves don't support netpoll?  

	How many network drivers don't support netpoll nowadays?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists