[ovs-dev] [PATCH] vswitch: Correctly identify slave status in /proc compatibility layer
Ben Pfaff
blp at nicira.com
Mon Sep 14 16:44:27 UTC 2009
Ian Campbell <Ian.Campbell at citrix.com> writes:
> On Mon, 2009-09-14 at 17:12 +0100, Ben Pfaff wrote:
>> Justin Pettit <jpettit at nicira.com> writes:
>>
>> > In the /proc compatibility layer, the bond member was reported as up
>> > immediately after link recovery, regardless of the updelay. I believe
>> > the compatibility code was correct if the check had been done with carrier,
>> > but since 'iface->enabled' already does that calculation, we can use it
>> > directly.
>>
>> My reading of the kernel bonding code was that that particular
>> value in /proc actually reports the carrier status, not whether
>> the slave is enabled or disabled. If I'm wrong, this commit
>> should be applied.
>
> bond_info_show_slave has the following code:
> seq_printf(seq, "MII Status: %s\n",
> (slave->link == BOND_LINK_UP) ? "up" : "down");
> slave->link is managed by the state machine in bond_miimon_inspect()
> which does:
> if (slave->delay <= 0) {
> slave->new_link = BOND_LINK_UP;
bond_miimon_inspect() supports four BOND_LINK_* states:
* BOND_LINK_UP: carrier detected, updelay has passed.
* BOND_LINK_FAIL: carrier lost, downdelay in progress.
* BOND_LINK_DOWN: carrier lost, downdelay has passed.
* BOND_LINK_BACK: carrier detected, updelay in progress.
bond_info_show_slave() only considers BOND_LINK_UP to be "up" and
anything else to be "down".
I think that the proper implementation of this behavior in the
vswitch compat code would actually be:
slave->up = iface->enabled && iface->delay_expires == LLONG_MAX;
i.e. interface is enabled and no downdelay is in progress.
More information about the dev
mailing list