[ovs-dev] [PATCH] datapath: compat: fix kernel module reference count.
Eric Garver
e at erig.me
Fri Nov 10 21:04:22 UTC 2017
On Fri, Nov 10, 2017 at 12:23:37PM -0800, William Tu wrote:
> >> After the dpif-netlink-rtnl, a tunnel device can be created by using
> >> rtnetlink, so the creation of fb device comes from the ovs-vswitchd
> >> instead of going through OVS kernel modules. This breaks the module
> >> dependency between 1) and 2). As a result, when ovs-vswitchd is running,
> >> the 'lsmod' shows:
> >> geneve 27326 1 vport_geneve
> >> vport_geneve 12560 0
> >> openvswitch 172469 1 vport_geneve
> >
> > Which is correct. vport_geneve is not using geneve. If anything is using
>
> Actually vport_geneve is using geneve. (Please correct me if I'm wrong)
> If we're using upstream tunnel (USE_UPSTREAM_TUNNEL=yes)
> then vport_geneve calls into kernel's geneve_dev_create_fb(), so it
> has symbol dependency.
Sure, but by that logic the compat interface is also broken in the same
way. I think if you start OVS with an empty config (no geneve tunnel
created), then you should have the same ref counts as above. You can
manually unload vport_geneve.
When USE_UPSTREAM_TUNNEL=yes OVS _does not_ functionally use
vport_geneve. It gets loaded because that's what OVS startup scripts do.
You can delete vport_geneve.ko and everything with still function with
the rtnetlink interface. I suggest renaming them, running depmod, and
giving it a try.
> If USE_UPSTREAM_TUNNEL=no, then geneve_dev_create_fb is replaced with rpl_xxx,
> then no dependency.
Agree. No dependency on in-kernel geneve driver.
> Can we say that if (OVS version == 2.8 && USE_UPSTREAM_TUNNEL=yes),
> then we don't need any vport-xxx implementation and we can remove these code?
Yes! But we still support older kernels (I think < 4.5-ish) that don't
support all the necessary features for tunnels. As such the OVS shipped
drivers will be around for awhile.
More information about the dev
mailing list