[Top] [All Lists]

Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address

To: Jay Vosburgh <fubar@xxxxxxxxxx>
Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 9 Apr 2005 08:16:29 +1000
Cc: davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, jgarzik@xxxxxxxxx
In-reply-to: <200504082059.j38KwhaG009173@xxxxxxxxxxxxxxxxxxxxxx>
References: <E1DJsiq-0006xJ-00@xxxxxxxxxxxxxxxxxxxxxxxx> <200504082059.j38KwhaG009173@xxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Fri, Apr 08, 2005 at 01:58:43PM -0700, Jay Vosburgh wrote:
>       There are several paths from a timer context, e.g.,
> timer -> bond_mii_monitor -> bond_change_active_slave ->
> bond_alb_handle_active_change -> alb_set_slave_mac_addr

Is that what it's for.  I sense an opportunity for you to
greatly clean up this section of code :)

The networking drivers are trying to switch over to using
netif_carrier_ok as the interface for notification and
monitoring of link status.  In fact, even the bonding driver
appears to do this by default.

When you're using netif_carrier_ok, you're relying on the
driver itself to monitor the physical status.  It will usually
do so in its own timer.

In other words, it's pointless to examine netif_carrier_ok
more often than the underlying driver timer.  The standard
interface to monitor its status is through a netdev
notification (NETDEV_CHANGE). That is called in process
context by net/core/link_watch.c.

So I'd suggest that we get rid of directly MII monitoring in
bonding, and always use netif_carrier_ok.  Further more,
instead of monitoring that in a timer you just move the code
into bond_netdev_event.

>       As I said above, the timer case doesn't have an obviously good
> way to change it to do the MAC sets in a sleepable context with no
> locks.  I also wonder how expensive it is to run work queue events every
> 10ms as compared to running timer events every 10ms?

If you really want to keep monitoring the MII status directly, then
you can still schedule the changing of the MAC address via a work

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

<Prev in Thread] Current Thread [Next in Thread>