Re: [PATCH net 3/3] bonding:force to use primary slave
From: Jay Vosburgh <hidden>
Date: 2012-06-11 21:17:34
Nicolas de Pesloüan [off-list ref] wrote:
Le 11/06/2012 11:00, Weiping Pan a écrit :quoted
When we set primary slave with module parameters, bond will always use this primary slave as active slave. But when we modify primary slave via sysfs, it will call bond_should_change_active() and take into account primary_reselect. And I think we should use the new primary slave as the new active slave regardless of the value of primary_reselect. Thus the behavior is the same with module parameters and meets the administrator's expectation. Signed-off-by: Weiping Pan<redacted> --- drivers/net/bonding/bond_sysfs.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c index 1b0f3cd..7256ae4 100644 --- a/drivers/net/bonding/bond_sysfs.c +++ b/drivers/net/bonding/bond_sysfs.c@@ -1077,6 +1077,7 @@ static ssize_t bonding_store_primary(struct device *d, bond->dev->name, slave->dev->name); bond->primary_slave = slave; strcpy(bond->params.primary, slave->dev->name); + bond->force_primary = true; bond_select_active_slave(bond); goto out; }Not sure this is the right behavior. One may want to change the primary without causing a switch to this primary if another slave is already active, and setup primary_reselect to failure or better for that reason. The administrator still have the option to write into active_slave, to force the new active slave after changing the primary. Arguably, this should be documented.
I suspect it is obeying the documented behavior, at least for the behaviors that are documented. The documentation already says that "When initially enslaved, the primary slave is always made the active slave." That's probably what covers the "module param" case, because the options are all set prior to any slaves being added, so when the primary slave is later enslaved, it is made the active slave immediately. Now, the documentation for the primary option itself also says: "The specified device will always be the active slave while it is available. Only when the primary is off-line will alternate devices be used." Which is the old behavior, prior to primary_reselect being added (although it is still the default behavior). This should probably change to reflect the actual behavior, i.e., that changing the primary option in real time results in a reselection of the primary according to the policy specified by primary_reselect. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com