Re: [RFC][PATCH 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices

[Or Gerlitz <ogerlitz@voltaire.com>]

Jay Vosburgh wrote:
> Or Gerlitz <or.gerlitz@gmail.com> wrote:
> 
>> On 9/26/06, Jay Vosburgh <fubar@us.ibm.com> wrote:
>>> Or Gerlitz <ogerlitz@voltaire.com> 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.