Message-ID: <4BA82110.6040201@redhat.com>
Date:	Tue, 23 Mar 2010 10:01:52 +0800
From:	Cong Wang <amwang@...hat.com>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	Matt Mackall <mpm@...enic.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

Jay Vosburgh wrote:
> 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?  
> 

I see, thanks for your explanation, I overlooked the bonding case.

The current implementation will totally disable netpoll when at least one
slave doesn't support netpoll, so it looks like a safe choice. ;)


> 	How many network drivers don't support netpoll nowadays?
> 

Only about 20% of network drivers support netpoll, a quick grep of 'ndo_poll_controller'
can show that.

Thanks a lot!
--
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