On Thu, May 10, 2012 at 04:02:29PM +0200, Giuseppe Lettieri wrote: > Hi everybody, > > I am Giuseppe Lettieri from Pisa (Italy) and I am working on integrating > Open vSwitch in PlanetLab. We are currently focusing on the user level > (aka 'netdev') datapath, since this is much simpler to use in PlanetLab. > > I have noticed that if I create a bridge with 'datapath_type=netdev' and > then delete it, the corresponding netdev datapath is not destroyed. In > particular, the tap interface created for the the bridge "internal" port > is not close()d, and therefore persists until ovs-vswitchd exit()s. This > is reproducible as follows (tested on git master branch, last commit: > 43d366785410bc7803e4b00ba59f99b7ca8185cc): > > ovs-vsctrl add-br br0 -- set bridge br0 datapath_type=netdev > # interface br0 appears > ovs-vsctrl del-br br0 > # interface br0 does not disappear > > This may not be a great problem in general, but it is an annoyance in > PlanetLab, since here tap interfaces have to be created in a peculiar > way that makes reopening them somewhat difficult. > > This behaviour appears to be triggered by the fact that the > 'dpif_netdev_class' does not implement the 'enumerate' method > (lib/dpfi-netdev.c:1244), and thus 'bridge_reconfigure' is not able to > see the dangling datapaths. Indeed, providing the method solves the > issue. Before definitely adding it, however, I would like to know if > there is any good reason for its omission. It looks like a very simple > method to implement, so I suspect I am missing some bigger problem with it.
Hmm. This does sound like the correct pattern for a fix, but will it cause OVS to delete tap devices that it didn't create? If not, then it definitely sounds right to me. Will you submit the patch to be included in upstream OVS? I'd appreciate that. Thanks for investigating. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
