> > Marking the master down would, I believe, issue notifiers that
> > the device has gone down. Various things, network manager sort of
> > applications in particular, listen to those, so I'm not sure it's a
good
> > idea. I think there are other side effects as well, I'm thinking it
> > would flush routes associated with the interface as well.
[BTW, you can call ip_mc_down()/ip_mc_up() directly w/o getting there
from the notifiers -- then no side-effects.]
Andy Gospodarek wrote:
>
> I agree with Jay here. I hate that bonding has to have so much
> knowledge about upper layer protocols, but for the ones that are
> stateful like IGMP we will need fixes like the one proposed.
I have no problem with bonding having knowledge of ULP's (I
don't like it, but I don't have to look at it :-) ), but the
patch is doing it the other way around. What I don't like about the
proposed patch is that it's adding knowledge of bonding to IGMP.
And IGMP does work fine in this case, w/o flooding or the
proposed patch. It just has the risk of losing multicast packets
during one query interval, and that only happens if you're
using a switch that does IGMP snooping.
I'd like the patch a lot better if it were basicly this:
mc_bond_fudge(void)
{
ip_mc_down(masterdev);
/*do whatever you need to do to switch the slave */
ip_mc_up(masterdev);
}
That doesn't go through the notifier chain, uses existing
functions, doesn't have any refcnt issues, and most importantly
could/should reside in a bonding source file and not in igmp.c. :-)
But RTNL is required whether you use up/down or roll your
own variant, so it sounds like you have other issues to resolve too.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
