On 12/17/2020 3:55 AM, Ilya Maximets wrote:
On 12/16/20 9:37 PM, Flavio Leitner wrote:
On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
On 11/12/20 6:04 PM, Gregory Rose wrote:
On 11/12/2020 5:10 AM, Mark Gray wrote:
On 30/10/2020 18:32, Gregory Rose wrote:
The question is whether there is any interest in continuing to support
the OVS out-of-tree (OOT) kernel driver or should we deprecate it? The
latest kernel support for the OOT driver is up to 5.8.x There seems to
be little interest that I can tell in using the OOT driver. The main
distros all include the kernel built-in OVS driver and those drivers
generally seem to support all the primary features required by user space.
Most of the energy on this list seems to be directed toward DPDK and OVN
and it doesn't seem to me that either of those require the OOT driver.
If there's no one actually using the OOT driver I suggest we deprecate
it and save time and energy on keeping it up to date.
Opinions, thoughts, comments?
I think it is good to raise this question. Thanks.
It would certainly simplify development of kernel features and avoid the
type of issue that I had recently with a patch in the OOT tree but not
upstream. As I don't know who uses OOT, I can't comment beyond that.
I'm knee deep in some work at my day job but when I get a
chance I'm going to send a patch for the faq, NEWS, etc. and request
that we deprecate the OOT driver and end support for newer kernels
at the current 5.8. After that we'll only take bug fixes.
I don't really believe there are any consumers for the OOT driver
on this list anymore. Certainly the lack of response to this
question indicates that.
CC: ovs-discuss
Thanks for raising this question.
As far as the topic goes, the only thing that might get people to use
the OOT module with kernels higher than 5.8 is SST or LISP support.
On the other hand, there were reasons to reject patches to support these
protocols in the mainline kernel. And I have no idea if anyone is actually
using them. I never used them and I'm not even sure if they actually work
taking into account that we have only 2 system tests for them that doesn't
really check much.
Maybe we could also raise the question during the conference to get more
attention. I'd like to add a reference into my "community updates"
presentation.
I know that it takes a lot of time to support OOT kernel module and it
doesn't seem worth the effort. I'd vote for deprecation and eventual
removal. Sending patches is a good idea, with them we could move forward
if no strong objections will appear. And thanks for all the work you did
supporting kernel module all that time!
Since the conference already happened, have you decided something?
IIRC, during the conference Han mentioned that they are relying on OOT module
for STT support. And I also noticed a patch from Vitaly to fix some issue
in STT part of the kernel module. Both CC-ed.
Han, Vitaly, do you have some thoughts about deprecation of OOT kernel
module and what is your usecase with STT? Is it critical for you to have
STT support here in upstream OVS?
I suggest to follow "Feature Deprecation Guidelines" section in
Documentation/internals/contributing/submitting-patches.rst with
the addition of warning when building that code for extra
visibility.
Sure, that is reasonable. We should have a deprecation warning in
configure script if '--with-linux' requested.
Best regards, Ilya Maximets.
I will work something up. I will be out for most of the holidays but
will try to have patches ready soon after the new year.
Thanks all for suggestions and input.
- Greg
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
