[ovs-dev] [PATCH 07/16] dpif-linux: Clean up vports that are no longer in config.
Ben Pfaff
blp at nicira.com
Thu Apr 15 21:06:10 UTC 2010
On Thu, Apr 15, 2010 at 04:45:41PM -0400, Jesse Gross wrote:
> On Wed, Apr 14, 2010 at 7:13 PM, Ben Pfaff <blp at nicira.com> wrote:
>
> > On Tue, Apr 13, 2010 at 10:41:09AM -0400, Jesse Gross wrote:
> > > If the config changes while ovs-vswitchd is not running it is possible
> > > that there could be some vports which are no longer needed but won't
> > > be destroyed when closed because they aren't open. This deletes
> > > unneeded vports at the same time that we clean up unneeded datapaths.
> >
> > Is it ever useful to keep around a vport that is attached to a dp at the
> > time of the datapath's destruction? If we are going to unconditionally
> > delete them from userspace, would it be better to do that from the
> > kernel?
> >
> >
> We don't currently ever keep them around but from an abstraction point of
> view it seems a little nicer since the lifetime of a vport exists beyond
> that of a specific datapath. I suppose we could add a flag to delete all
> attached vports in the future if this is a problem.
>
>
> > In dpif_linux_destroy(), should we really give up with an error if any
> > of the calls fail? Would it be better to continue along the way and
> > finish up deleting the datapath before reporting the error? I doubt the
> > callers actually retry, but they probably do really want to delete the
> > datapath.
> >
>
> Probably not. At point there were some potential resource leaks but it is
> more robust now. I changed it to log the error but continue on.
OK, this all sounds reasonable, thanks.
More information about the dev
mailing list