[ovs-dev] [PATCH] Add some developer documentation on the bonding implementation.

Justin Pettit jpettit at nicira.com
Wed Sep 9 11:24:32 UTC 2009

On Sep 8, 2009, at 9:04 PM, Ben Pfaff wrote:

> +These packets teach the physical
> +switch the new slave to use for packets destined for the vswitch's
> +other, non-bonded ports.  (This behavior probably makes sense only  
> for
> +a vswitch that has only a single physical port (the bond); vswitchd
> +should probably provide a way to disable or configure it in other
> +scenarios.)

These last couple of sentences on disabling a slave confused me.   
Isn't sending these gratuitous learning packets also useful for  
teaching the physical switch about how to reach guest VMs?  Also, the  
parenthetical portion seemed to contradict the previous sentence,  
since the first part states that this is useful for "other, non-bonded  
ports", but then it states that this only makes sense for vswitches  
with a "single physical port (the bond)".  Calling the bond a  
"physical port" was also confusing to me, since I think of it as a  
virtual port.

> +vswitchd provides the following bond-related commands.  These  
> commands
> +may be invoked using "ovs-appctl -t <target> -e '<command>":

I think you need another single quote just before the closing double  

> +bond/migrate <port> <hash> <slave>
> +    Assigns a given MAC hash to a new slave.  <port> specifies the
> +    bond port, <hash> either the MAC hash to be migrated (as a  
> decimal
> +    number between 0 and 25) or an Ethernet address to be hashed, and

Is that 25 supposed to be 255?

> +bond/enable-slave <port> <slave>
> +bond/disable-slave <port> <slave>
> +    Enables (or disables) <slave> on the given bond <port>.
> +
> +    This setting is not permanent: it persists only until the carrier
> +    status of <slave> changes.

Is the purpose of this to override the updelay and downdelay  
settings?  If so, it may be nice to explicitly state that.


More information about the dev mailing list