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