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

[Gregory Rose]

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