[ovs-dev] [PATCH] dpif: Ensure ERSPAN GRE support

Eric Garver e at erig.me
Mon Jun 4 14:29:35 UTC 2018


On Fri, Jun 01, 2018 at 11:23:12AM -0700, William Tu wrote:
> On Fri, Jun 1, 2018 at 9:38 AM, Jiri Benc <jbenc at 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.


More information about the dev mailing list