From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Jiri Pirko <jpirko@redhat.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, fubar@us.ibm.com,
bonding-devel@lists.sourceforge.net
Subject: Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
Date: Mon, 24 Aug 2009 17:07:18 +0200 [thread overview]
Message-ID: <4A92ACA6.7070600@free.fr> (raw)
In-Reply-To: <20090824111619.GC4018@psychotron.englab.brq.redhat.com>
Jiri Pirko wrote:
> Thu, Aug 20, 2009 at 02:40:07PM CEST, nicolas.2p.debian@free.fr wrote:
[--cut--]
>> I suggest that instead of having a per bond "primary_lazy" option, we
>> define a per slave option, describing whether this particular slave is
>> "sticky when active" or not.
>>
>> The above setup would become :
>>
>> echo 1 > /sys/class/net/eth0/bonding/sticky_active
>> echo 1 > /sys/class/net/eth1/bonding/sticky_active
>> echo 0 > /sys/class/net/eth2/bonding/sticky_active
>> echo eth0 > /sys/class/net/bond0/bonding/primary
>>
>> Or may be better, keeping the "weight" idea in mind, a per slave option
>> "active_weight" that gives the weight of the slave, *when active*.
>>
>> The effective weight of a slave would become :
>>
>> effective_slave =
>> (is_active ? user_supplied_active_weight ? user_supplied_weight) *
>> natural_weight
>>
>> # Prefer eth0, then one of eth1 or eth2, then eth3.
>> echo 1000 > /sys/class/net/eth0/bonding/weight
>> echo 999 > /sys/class/net/eth1/bonding/weight
>> echo 999 > /sys/class/net/eth2/bonding/weight
>> echo 10 > /sys/class/net/eth3/bonding/weight
>>
>> # Do not switch back to primary eth0 if eth1 or eth2 is active.
>> echo 1000 > /sys/class/net/eth1/bonding/active_weight
>> echo 1000 > /sys/class/net/eth2/bonding/active_weight
>>
>> Every time one changes the user_supplied_weight, then
>> user_supplied_active_weight must be reset to the same value. This way,
>> if no special setup is done on active_weight, then the current normal
>> behavior is achieved.
>
> I must say I like this approach. But it would be not trivial to implement this.
> Therefore I would stick with your propose of extending primary lazy to 3 values
> until the weight option is implemented.
It sounds good for me. Later, if I eventually implement the weight option, it
shouldn't be that hard to convert internally the primary_lazy setup to
active_weight, the same way we plan to convert internally primary setup to
weight setup.
primary and primary_lazy are convenient for simple - two slaves only -
configurations. weight and active_weight are for more advanced configurations.
Keeping both configuration interface does sound user friendly.
> I'm going to implement your propose below.
By the way, even if I'm not a native English speaker, I think that primary_lazy
option should be named lazy_primary instead.
Nicolas.
>> If none of those options seem acceptable to you, I suggest a third one:
>>
>> You keep primary_lazy, but with the following values :
>>
>> # Switch back to primary slaves when it comes back.
>> echo 0 > /sys/class/net/bond0/bonding/primary_lazy
>>
>> # Switch back to primary when it comes back, only if the speed of the
>> # primary slave is higher than the speed of the current active slave.
>> echo 1 > /sys/class/net/bond0/bonding/primary_lazy
>>
>> # Stick to the current active slave when the primary slave comes back,
>> # even if the primary slave speed is higher than the speed of the
>> # current active slave.
>> echo 2 > /sys/class/net/bond0/bonding/primary_lazy
>>
>> You can consider the value as being the level of laziness of the primary.
>>
>> Nicolas.
>>
next prev parent reply other threads:[~2009-08-24 15:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 15:05 [PATCH net-next-2.6] bonding: introduce primary_lazy option Jiri Pirko
2009-08-13 15:44 ` Jay Vosburgh
2009-08-14 10:52 ` Jiri Pirko
2009-08-13 19:41 ` [Bonding-devel] " Nicolas de Pesloüan
2009-08-14 10:59 ` Jiri Pirko
2009-08-14 16:27 ` Nicolas de Pesloüan
2009-08-17 11:49 ` Jiri Pirko
2009-08-17 20:55 ` Nicolas de Pesloüan
2009-08-18 12:45 ` Jiri Pirko
2009-08-20 12:40 ` Nicolas de Pesloüan
2009-08-24 11:16 ` Jiri Pirko
2009-08-24 15:07 ` Nicolas de Pesloüan [this message]
2009-08-24 15:20 ` Jiri Pirko
2009-08-24 17:35 ` Jay Vosburgh
2009-08-25 6:43 ` Jiri Pirko
2009-08-25 17:31 ` Nicolas de Pesloüan
2009-08-25 18:41 ` Jay Vosburgh
2009-08-25 20:33 ` Nicolas de Pesloüan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A92ACA6.7070600@free.fr \
--to=nicolas.2p.debian@free.fr \
--cc=bonding-devel@lists.sourceforge.net \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=jpirko@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.