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 > <casca...@redhat.com> 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? 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? Cascardo. > > I don't think this check is necessary because as I said: if creating the > > netdevice fails, we will use the compat layer. And we should give priority > > for > > the netdevice option, because it supports more options. With the out-of-tree > > tunnels code as of now, whenever we try to create the device, it will fail, > > so > > we will fallback anyway. This patch was exactly trying to allow using those > > drivers with the new method, in order to allow those new options to be > > supported > > with the out-of-tree drivers. > > > > If you think we don't need to support those out-of-tree drivers with the new > > options, no problem. We will just drop this patch. Otherwise, we might need > > to > > fix it. But so far, I don't see any necessary changes to the userspace part > > that > > has already been submitted. Which way should we go? > > > > Thanks. > > Cascardo. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
