On 10 November 2017 at 22:54, Gregory Rose <[email protected]> wrote:
> On 11/11/2017 9:57 AM, William Tu wrote: > >> yes, this is an artificial dependency. Another way I'm thinking is for >>>> ovs-vswitchd >>>> to hold the geneve.ko dependency instead of openvswitch.ko, when user >>>> creates >>>> a geneve device. Is there a way to do that through rtnetlink or at >>>> dpif_netlink_rtnl_create()? >>>> >>> It should be vport-netdev doing the magic. It creates the linkage with >>> netdev_master_upper_dev_link(), but apparently that is not enough to >>> bump the kernel module refcnt and thus prevent unloading. Maybe you can >>> dig into why that is. AFAICS, it should be linking openvswitch.ko and >>> and geneve.ko with that call. >>> >> Sure, will take a look. >> > > I'm extremely uncomfortable with this approach of manually bumping a > driver refcnt. > I worry we're going to get into a situation where the driver won't > *unload*. In a properly > configured system this shouldn't be necessary. Driver dependencies > shouldn't have to > be manually configured. > Hypothetically, let us assume that we use only upstream "geneve". Once we create tunnel via it, it shouldn't be possible to remove it. But right now, we can. And I think that is wrong. > > Why do we have a vport-geneve driver loaded when there is a geneve driver > already > built in to the kernel? OVS startup scripts will load one, if previously there was one used. This happens when we upgrade from 2.7 to 2.8. There is a patch proposed to remove that option. > What is the OVS vport-geneve driver providing that the built-in > kernel geneve driver does not provide? > > - Greg > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
