[ovs-discuss] [ovs-dev] Question about supporting the OVS out-of-tree kernel drivers

[Ilya Maximets]

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.