On 6/1/2018 9:38 AM, Jiri Benc 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.
Jiri,
I think there must be some confusion here. The compat interface should
be used to support
features that are not in the kernel. ERSPAN in this case. ERSPAN is
introduced in 4.16 (let's
just agree to ignore 4.15 since it's not LTS).
So in kernels up to and including 4.14 we must use the compat interface
to get ERSPAN support
correct?
If there is another way to do it I'm all ears.
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.
So how do we support ERSPAN in kernels that don't have it? I thought
that's what the
compat layer code is there for.
Thanks,
- Greg
Please go read what Eric described about reading the value back.
As for the patch,
Nacked-by: Jiri Benc <[email protected]>
Jiri
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev