[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