On Fri, Jun 01, 2018 at 11:23:12AM -0700, William Tu wrote: > On Fri, Jun 1, 2018 at 9:38 AM, Jiri Benc <jb...@redhat.com> wrote: > > On Fri, 1 Jun 2018 09:15:33 -0700, Gregory Rose wrote: > >> Since ERSPAN over gre/ip_gre was added to the Linux 4.16 kernel the > >> compat interface is needed > >> for kernels up to 4.15 so that we can support ERSPAN. If the built-in > >> gre/ip_gre kernel modules > >> don't have the ERSPAN support in them then we have to use the compat > >> interface. > > > > That's very wrong. The compat interface should not be used with > > upstream kernel (except perhaps for very very very old kernels). We > > converted the API to the standard rtnetlink for good reasons. New > > features are not supported using the compat API. You are potentially > > breaking future distribution kernels by reverting to an obsolete and > > deprecated API. > > > > You'll have to find a different way to do what you need. Eric described > > pretty nicely a way to achieve that and how the fallbacks work, please > > re-read his emails and modify the code accordingly. > > > >> The target for USE_UPSTREAM_TUNNEL is moved to 4.16 now. That's when > >> ERSPAN becomes > >> fully supported. Going forward the ERSPAN feature is the determinant > >> for whether gr/ip_gre > >> compat mode is used or not. > > > > And with the next added feature to the kernel, that next feature will be > > what determines whether the compat mode will be used? And then next and > > so on? This doesn't work. ERSPAN must not be the decision factor. > > Instead, rtnetlink must be tried first and if and only if it fails, > > compat mode can be used. > > > > Please go read what Eric described about reading the value back. > > > Thanks for the feedback. > > Looking at the dpif_netlink_rtnl_probe_oot_tunnels(), since now we > added ERSPAN feature, instead of probing geneve module, > we should probe ip_gre module with a nlattr of ERSPAN (ex: HWID). > If it does not return -ENOSUPPORT, then use the upstream ip_gre module. > > And the next added feature should change this function to determine > whether to use compat mode or not. Do I understand it right?
If we're going to continue adding new features to the out-of-tree (OVS shipped) modules then instead of using the compat interface by default the rtnetlink interface should always be tried first - with a fallback to compat (this catches things like LISP/STT). New features in the out-of-tree modules are then exposed via rtnetlink just like the in-tree modules. Code in lib/dpif-netlink-rtnl.c, vport_type_to_kind(), would need to be modified to try the "ovs_" prefix kinds. dpif_netlink_rtnl_probe_oot_tunnels() would the trigger for trying the "ovs_" prefixed kinds. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
