[ovs-dev] [PATCH 1/2] ovs-ctl.in: Ability to save flows and kernel datapath config.

Gurucharan Shetty gshetty at nicira.com
Fri Oct 19 21:03:59 UTC 2012

On Fri, Oct 19, 2012 at 1:19 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Fri, Oct 19, 2012 at 11:06:27AM -0700, Gurucharan Shetty wrote:
> > Add a new command - "restart" to ovs-ctl. Calling this command
> > will save and restore the Openflow flows on each bridge while
> > stopping and starting the userspace daemons respectively.
> >
> > Also, during a force-reload-kmod, save the flows and kernel datapath
> > configuration. Use the saved datapath configuration while readding
> > the kernel module and the flows while starting the userspace daemons.
> >
> > Feature #13555.
> > Signed-off-by: Gurucharan Shetty <gshetty at nicira.com>
> Thanks for doing this work.  Working on the startup scripts is
> difficult work.
> I think that "ovs-save save-flows" creates additional temporary files,
> with mktemp, that never get removed.  If so, one way to avoid that
> would be to write to a single script commands of the form:
>         ovs-ofctl add-flows <bridge> - <<EOF
>         ...flows...
>         EOF
> (In that case, logging the entire script for restoring the flows is no
> longer a good idea.)
The reason I chose to go ahead with the undeleted tmp files model
was that the tmp files could be used to debug the issue
later if restoring flows fail for some reason. But I guess, it is bad
etiquette to leave them undeleted.

> It looks like force-reload-kmod will create two temporary files and
> try to ensure that both of them are deleted with two separate commands
> like this:
>     trap 'rm -f "${script_flows}"' 0 1 2 13 15
> But each "trap" for a signal replaces the previous one, so only one of
> those files will actually be deleted.
I will correct this.

> The logging seems more elaborate than I would expect in
> restore_datapath and in stop_forwarding.  These functions now log the
> commands that they are running and their success or failure.  Although
> that's reasonable to do, if we are going to do it for these particular
> actions then I'd think we'd want to do that for pretty much every
> action.  (If you think that's a good idea then I'd be OK with it.)

I looked at the model we have for "Restoring interface configuration"
action and I was confused about what to do for the 2 new additions
that I am making. I will get rid of the logging for the 2 new additions.
Should I keep the old logging intact?

> I think that this will save the old flows even if one runs plain
> "stop", which is just a waste in that case.  I think it would be
> better to only save them for the cases where they will be used
> ("force-reload-kmod" and "restart", right?).
I will correct this.

In force_reload_kmod, this change moves stopping ovs-vswitchd from
> after starting and stopping the database to before starting and
> stopping the database.  That will extend the period of time when new
> flows cannot be set up.  Is it really necessary to do it?
In stop_forwarding, I use 'ovs-vsctl list-br' command which needs the
database. According to the comment in the code, starting a large database
may take time. So, I wanted to save the flows first and then stop the

> For the same reason, in the "restart" case, is it possible to change
> the order to stop/start ovsdb, then stop/start ovs-vswitchd?
Out here too, I will need the bridges before hand. Wouldn't it delay things
if I start the database first? I can get the bridges first, and then stop
the database.

> In force_reload_kmod, it would be better, if it is possible, to save
> the datapaths after stopping ovs-vswitchd, because that avoids a race
> between saving the datapaths and ovs-vswitchd modifying them.
I will correct this.

> It's not obvious to me why saving datapaths and saving interfaces are
> separate steps.  Can we combine these steps?
Are you saying, make a single function call to ovs-save? Or make 2 function
calls, but use the same script to store the results?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20121019/3bd7a348/attachment-0003.html>

More information about the dev mailing list