[ovs-dev] [PATCH] bridge: Rate limit port creations and deletions.

Ben Pfaff blp at nicira.com
Thu Apr 12 09:31:54 PDT 2012

On Wed, Apr 11, 2012 at 12:10:13AM -0700, Ethan Jackson wrote:
> In some datapaths, adding or deleting OpenFlow ports can take quite
> a bit of time.  If there are lots of OpenFlow ports which needed to
> be added in a run loop, this can cause Open vSwitch to lock up and
> stop setting up flows while trying to catch up.  This patch lessons
> the severity of the problem by only doing a few OpenFlow port adds
> or deletions per run loop allowing other work to be done in
> between.
> Bug #10672.
> Signed-off-by: Ethan Jackson <ethan at nicira.com>

We're using the number of ports added or deleted as a proxy for the
amount of time that we can afford to spend reconfiguring.  Did you
consider instead directly measuring the amount of time we've spent
reconfiguring?  For example, we could say that we'll continue to add or
delete ports during a particular iteration until 10 ms have elapsed, and
then defer the rest to the next iteration.

I would declare the new variable ofp_port_action_count inside
bridge_reconfigure() and pass its address to the functions that need it
(only two), to keep global variables to a minimum.

bridge_reconfigure() sets need_reconfigure to false initially and then
later sets it to true in one case.  It might be more straightforward to
do both at once, e.g.:
        need_reconfigure = ofp_port_action_count >= MAX_OFP_PORT_ACTIONS;

At the end of bridge_reconfigure(), I think that we should call
daemonize_complete() only if need_reconfigure is false.  Otherwise
force-reload-kmod will have a race if there are more than 5 ports; see
commit a7ff9bd76312 (ovs-vswitchd: Complete daemonization only after
initial configuration.).

The style of the new log messages clashes with the style of the ones
that you removed.  I would suggest "bridge %s: removed interface %s
(%d)" and "bridge %s: added interface %s (%d)" which fit in better and
give both name and number.



More information about the dev mailing list