[ovs-dev] [add-remove v2 7/8] vswitchd: Better tolerate changes in datapath ports.

[Jesse Gross]

On Fri, Oct 1, 2010 at 4:48 PM, Ben Pfaff <blp at nicira.com> wrote:
> Until now, a command that removed and added ports in a single change to
> the database, e.g.:
>        ovs-vsctl del-port br0 vif1.0 -- add-port br0 vif2.0
> typically failed, because of this sequence of events:
>
> 1. Bridge code removes vif1.0 from br0.
> 2. Bridge code adds vif2.0 to br0.
> 3. ofproto_run() receives kernel notification that vif1.0 was deleted, so
>   it notifies the bridge by calling back to bridge_port_changed_ofhook_cb,
>   which sees that it has an interface with the specified port number, and
>   deletes it.  Oops--this is where the problem occurs.  For completeness:
> 4. ofproto_run() receives kernel notification that vif2.0 was added, so
>   it notifies the bridge by calling back to ,
>   which sees that it has no interface with the specified port number, and
>   does nothing.
>
> This commit fixes the problem by making bridge_port_changed_ofhook_cb() not
> care about ports being dropped.  This is a corner case that we shouldn't
> work too hard to care about, since it can only happen if an administrator
> is meddling with datapaths using ovs-dpctl, and the consequences are simply
> that packets directed to that device will take longer to be rerouted to
> another device (it will take a while for the MAC learning table to time out
> the entry).  Basically, the admin gets what he deserves.
>
> Thanks to Jesse Gross for identifying the problem.
>
> Bug #3671.

Looks good.  I agree, we shouldn't worry about people doing weird
things with ovs-dpctl.