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. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss