Re: [RFC Patch 3/3] bonding: make bonding support netpoll

[Cong Wang]

Jay Vosburgh wrote:
> Matt Mackall <mpm@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/