Re: [BUG?] bonding, slave selection, carrier loss, etc.

[Ben Hutchings <bhutchings@solarflare.com>]

On Fri, 2012-02-10 at 17:53 -0800, Jay Vosburgh wrote:
> Chris Friesen <chris.friesen@genband.com> wrote:
> 
> >I'm resurrecting an ancient discussion I had with Jay, because I think
> >the issue described below is still present and the code he talked about
> >submitting to close it doesn't appear to have ever gone in.
> 
> 	Yah, I never got it to work quite right; I don't remember
> exactly why.
> 
> >Basically in active/backup mode with mii monitoring there is a window
> >between the active slave device losing carrier and calling
> >netif_carrier_off() and the miimon code actually detecting the loss of
> >the carrier and selecting a new active slave.
> >
> >The best solution would be for bonding to just register for notification
> >of the link going down.  Presumably most drivers should be doing that
> >properly by now, and for devices that get interrupt-driven notification
> >of link status changes this would allow the bonding code to react much
> >quicker.
> 
> 	A quick look at some drivers shows that at least acenic still
> doesn't do netif_carrier_off, so converting entirely to a notifier-based
> failover mechanism would break drivers that work today.
[...]

It might be worth having some sort of feature flag (in priv_flags) that
indicates whether the driver updates the link state.  Alternately,
disable polling of a device once you see a notification.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.