On Thu, Sep 22, 2016 at 5:44 PM, Flavio Fernandes <fla...@flaviof.com> wrote: >> On Sep 22, 2016, at 6:53 PM, Jesse Gross <je...@kernel.org> wrote: >> When an OVS vport is created, a reference is taken on the >> corresponding vport-*.ko module. However, in the case of internal >> ports created by the datapath, the internal device vport is actually >> part of the main OVS module and so we are taking a reference on >> ourselves. As a result, the only way to unload the module is to delete >> all of the datapaths. It seems like this is what is happening here and >> is what force-reload-kmod is working around. >> >> Obviously, there's no benefit in taking a reference on ourselves, so >> we could just check for this and not take a reference. Combined with >> the fact that lightweight tunnels eliminates the need for vport >> modules that are not part of OVS (on new enough kernels), then >> unloading the module would be enough to gracefully cleanup everything. > > Very interesting, Jesse. In my little experiment, I create no logical switches > or any other config, so you are likely talking about datapath in terms of > the connectivity between the ovn-controller and the ovsdb server that is > managing the southbound database?!?
I was referring to datapaths as instantiated in the kernel module. If you have any ports attached to OVS - VMs, containers, tunnels, etc. then a datapath will exist. Unfortunately, I'm not going to have a chance to create a patch for this. However, if you want to give it a try, I would look at the call to try_module_get() in datapath/vport.c:ovs_vport_add(). That's where the reference to the vports are being taken and where we should check if the module being refcounted is actually us. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
