On 9/27/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
>+ /* XXX set the bond dev type and addr len such that the net core code
>+ * (eg arp_mc_map() in net/ipv4/arp.c) would correctly process multicast
>+ * groups set ***before*** the first enslaveness
>+ */
>+ bond_dev->type = bonding_dev_type;
>+ bond_dev->addr_len = bonding_dev_addrlen;
I've been thinking about this a little bit more. The system is
understandably not set up to deal with this situation, since normal
devices won't ever change their hardware type.
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.
A side effect of this is that bonds would have to be restricted
to consisting only of slaves of one hardware type, since slave changes
(and thus hardware type changes) aren't necessarily restricted to user
context.
I have addressed the point of putting slaves of different types (and
specifically slave of type ARPHRD_INFINIBAND with slave of other type
in the same bond) in the thead that goes with patch 1/3, let close it
there...
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.
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
