[ovs-discuss] [ovs-dev] Question about supporting the OVS out-of-tree kernel drivers
fbl at sysclose.org
Wed Dec 16 20:37:29 UTC 2020
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"
> 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?
I suggest to follow "Feature Deprecation Guidelines" section in
the addition of warning when building that code for extra
More information about the discuss