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? Regards, William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev