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).
[...]
>> 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.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
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
