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

[Ilya Maximets]

On 12/17/20 6:24 PM, Gregory Rose wrote:
> 
> 
> 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

Thanks!

Jan 1 is a soft freeze for current release, but I think it'll be fine to
accept these changes after that time.  So, no rush.

Best regards, Ilya Maximets.