[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1328986371.325.7.camel@deadeye>
Date: Sat, 11 Feb 2012 18:52:51 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Jay Vosburgh <fubar@...ibm.com>
CC: Chris Friesen <chris.friesen@...band.com>, <andy@...yhouse.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [BUG?] bonding, slave selection, carrier loss, etc.
On Fri, 2012-02-10 at 17:53 -0800, Jay Vosburgh wrote:
> Chris Friesen <chris.friesen@...band.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists