[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