Or Gerlitz [off-list ref] wrote:

On 9/26/06, Jay Vosburgh [off-list ref] wrote:

quoted

Or Gerlitz [off-list ref] 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).

[...]

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.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com