Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
On 9/26/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
[...]
+ bond->dev->mtu = new_active->dev->mtu;
This won't generate a NETDEV_CHANGEMTU notifier event.
What is actually the trigger for the event with the current impl? is
the code that actually calls dev_set_mtu() on the bonding device or
dev_set_mtu() itself?
My comment wasn't quite totally thought out; pretend you didn't
see it.
I think what would be better overall is to handle the mtu for
this case the way bonding handles the mtu for other slave devices.
Normally, the mtu is pushed to the slaves from the bonding master, not
the other way around. So, you don't want to assign the master's mtu
here; the slave mtu should already be up to date (and set to whatever
the master's mtu is via the usual mechanism, bond_change_mtu for
changes, or set in the slave at enslavement time).
OK, i think i got you. Today the dev_set_mtu() is called on the slave
device only when someone attempts to change the bond MTU. So you suggest
to do it also during enslavement so the current master MTU would be
propagated to the slaves and not vise versa, this makes sense.
[...]
So at the bottom line, i would go on enhancing my patch not to allow
bonding together devices of different types or at least if you don't
mind, not to allow putting ARPHRD_INFINIBAND with
non-ARPHRD_INFINIBAND devices in the same bond.
I think this (disallowing bonding of dissimilar ARPHRD types) is
the way to go, at least in the short term. Get it to work for the
common case first, then deal with the fringe stuff later.
OK, as you are fine with it, i will modify the patch to disallow bonding
of dissimilar ARPHRD types.
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
