Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
On 9/27/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
[...]
You almost want to have some kind of call to induce a reload
from scratch of the multicast filter settings (along with whatever else
might be necessary to alter the hardware type on the fly), to be called
by bonding at the time the first slave is added (since slave adds happen
in user context, and can therefore hold rtnl as required by most of the
multicast address handling code). That seems less hassle than having to
specify the hardware type and address length at module load time.
I agree that it would be better to avoid doing it this way.
Actually, it would be ideal to do it this way in all cases, as
the change of hardware type is the biggest hurdle to cross-hardware
bonding instances. The current infrastructure simply won't allow it,
though, since bonding failover events usually occur in a timer context
(if memory serves, timers run in softirq and can't acquire rtnl).
Sorry, but I don't follow... by saying "would be ideal to do ***it***
this way in all cases" what exactly is the "it" you are referring to?
[...]
Other random thoughts on how to resolve this include modifying
bonding to accept slaves when the master is down (which would also
require changes to the initscripts that normally configure bonding), so
that the initial setting of the, e.g., 224.0.0.1 multicast hardware
address happens to the already-changed hardware type.
OK, this is a direction i would like to check. Can be nice if you
provide me with a 1-2 liner of directions on what need to be changed
to enable bonding to accept slaves when it down.
I don't think right offhand this would be a particularly
difficult change; the "up" operation for bonding mostly just starts up
various timers. A few minutes poking around doesn't reveal anything
obvious that would hinder enslaving with the master down. You'll have
to change ifenslave and the sysfs code to allow enslaves with the master
down; that might be all that's needed for bonding itself. Changing
/sbin/ifup and friends is a separate problem.
OK, lets see i follow:
1st, your current recommendation to solve the link layer address
computation of multicast groups joined by the stack before any
enslavement actually takes place, is to instrument the bonding code such
that it would be possible to enslave devices when the bonding device is
not "up" yet.
2nd, the change need to be worked out in the bonding sysfs code, the
ifenslave program but ***also*** in packages such as /sbin/ifup and friends.
???
BTW - is the ifenslave program still supported to work with upstream
(2.6.18 and above) kernel or it was obsoleted at some point.
Or.
-
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
