[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29661.1199379831@death>
Date: Thu, 03 Jan 2008 09:03:51 -0800
From: Jay Vosburgh <fubar@...ibm.com>
To: "Jari Takkala" <Jari.Takkala@...com>
cc: netdev@...r.kernel.org
Subject: Re: [PATCH 2.6.23.12] net/bonding: option to specify initial bond interface number
Jari Takkala <Jari.Takkala@...com> wrote:
>On Wednesday, January 02, 2008 17:24, Jay Vosburgh wrote:
>> What advantage does this have over:
>>
>> # echo +bond5 > /sys/class/net/bonding_masters
>>
>> which will create a new bonding master for the already-loaded driver?
>>
>
>The advantage is that you can load multiple instances of the bonding
>driver and control the name of the bond interface that will be
>created. Normally the bond interface name would take the next available
>number.
>
>In our startup scripts we need to be able to ensure that the interface
>name is consistent across reboots. Sometimes bond1 may be brought up
>before bond0 and it may have different options (requiring a different
>instance of the bonding driver).
With the sysfs interface to bonding, your last statement is not
true; any number of bonding interfaces, with arbitrary names, can be
created and have their options set without loading multiple instances of
the bonding driver.
>I understand that the startup scripts could be modified to account for
>this, however we also have an IOS like interface to an embedded system
>where the user can create new bond interfaces and specify the interface
>number, they may create interfaces out of order and this feature enables
>them to accomplish that.
Does your embedded system have sysfs available? If it does,
then it's to your advantage to use the sysfs API; for one thing, the
single instance of the bonding driver with all interfaces through it
should utilize fewer resources than loading the driver repeatedly.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists