On Thu, Oct 27, 2016 at 5:08 AM, Thadeu Lima de Souza Cascardo <[email protected]> wrote: > On Wed, Oct 26, 2016 at 02:05:22PM -0700, Pravin Shelar wrote: >> On Wed, Oct 26, 2016 at 2:55 AM, Thadeu Lima de Souza Cascardo >> <[email protected]> wrote: >> > On Tue, Oct 25, 2016 at 08:21:55PM -0700, Pravin Shelar wrote: >> >> > The fallback option should already work, then. We can make sure during >> >> > testing >> >> > that is the case, so there would be no need to verify ovs_vxlan is >> >> > present in >> >> > case 3. Would that be OK for you? >> >> > >> >> I am not sure how exactly fallback would work. But I think we need to >> >> check ovs_geneve (or ovs_vxlan, ovs_gre) to see if we need to use >> >> netdev-vport in userspace. >> >> >> > >> > The fallback to compat layer happens whenever creating the netdev interface >> > fails to create it with the expected parameters. In the case of VXLAN and >> > Geneve, if we use the metadata option with no destination, creation will >> > fail, >> > and, then, we fallback to using vport compat mode. In the case of GRE, we >> > need >> > to read the parameters back and check for the metadata option, all of >> > which my >> > last version of the patch does. >> > >> >> > So, in summary, we drop this patch, submit what we had before, make >> >> > sure it >> >> > works in the following scenarions: >> >> > >> >> > 1) upstream ovs and tunnels are used; >> >> > 1a) metadata tunnels can be created, those are used; >> >> > 1b) we use compat vports if the configuration allows that; >> >> > >> >> > 2) out-of-tree ovs and out-of-tree tunnels are used; >> >> > we make sure using rtnetlink will fail and compat vport is used; >> >> > NOTE: this should work even with the old out-of-tree code that named >> >> > drivers as vxlan instead of ovs_vxlan. >> >> > >> >> > 3) out-of-tree ovs and upstream/in-tree tunnels are used; >> >> > it should work just like with upstream ovs, unless the out-of-tree >> >> > code does >> >> > not support metadata tunnels, in which case, it should fallback to >> >> > compat >> >> > code. >> >> > >> >> > In all cases, whenever a tunnel configuration that is not supported is >> >> > used, it >> >> > will fail to setup the tunnel. For example, if GPE would be used and it >> >> > was not >> >> > supported by creating the netdev, it won't work as well. As the compat >> >> > code does >> >> > not receive new features, when out-of-tree tunnel drivers are used, >> >> > those new >> >> > features won't be supported. >> >> > >> >> > One question that is left (though I tried to cover it in the scenarios >> >> > above) >> >> > is: do we need to support "old" out-of-tree versions with the new >> >> > userspace? >> >> > That is, if the user updates the userspace, should we require that the >> >> > out-of-tree kernel datapath be updated to the matching release? In that >> >> > case, we >> >> > don't need to test the new userspace with the old kernel datapath. >> >> > >> >> >> >> Yes, userspace should work with older datapath. There is no need to >> >> explicitly check for datapath. >> >> we could probe for device type in following order to detect kernel >> >> datapath support: >> >> >> >> 1. probe for ovs_geneve: If successful user comapt layer otherwise step 2. >> >> 2. probe for the LWT netdevice (e.g. vxlan or geneve). if sucessful >> >> use it. otherwise use netdev-vport type to manage tunnels. >> >> >> >> The idea is to give priority to compat implementation if it is >> >> defined. so we need to check for ovs_geneve devices first. >> > >> > I agree that there should be no need to check for the specific datapath. I >> > am >> > just considering the case where we had out-of-tree tunnels named "geneve" >> > instead >> > of "ovs_geneve". So, I don't think we should check for "ovs_geneve" at >> > all: it >> > will fail for older versions of the out-of-tree tunnels, and it's not >> > necessary. >> > >> If OVS compat layer renames the geneve implementation to "geneve" then >> user can not even use the kernel geneve driver if OVS module is >> loaded. That is the reason for having separate name. >> Do you see any issue with probing for device type "ovs_geneve"? >> > > If ovs_geneve can be created using rtnetlink and support the new options, as > we > intended with this patch, sure. That was our intention with this RFC. Then, we > are back to the path that we were in: adding support to the out-of-tree tunnel > code so we could create the devices using RTM_NEWLINK. Do you mean that? > We can not create compat tunnel device and attach it as netdev due to reasons mentioned before.
> Otherwise, as I said, I find it unnecessary to probe for ovs_geneve, unless > loading the in-tree driver will prevent the out-of-tree driver to be loaded. > In > which case, we are prefering the out-of-tree driver over the in-tree one no > matter what. > > Does that make sense? > Yes, we need to prefer out-of-tree tunnel driver in some kernel configuration. We already have that logic in compat code to determine those cases. in those cases compat code exposes ovs_geneve or ovs_vxlan tunnel devices. So the reason to probe for ovs_geneve is that it tells us if we should prefer out-of-tree tunnel driver or in-tree tunnel driver. I am not sure how would you figure out which tunnel implementation to use without probing for ovs_geneve. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
