On 5/19/22 20:04, Gregory Rose wrote: > > > On 4/15/2022 2:42 PM, Greg Rose wrote: >> It is time to remove support for the OVS kernel driver and push >> towards use of the upstream Linux openvswitch kernel driver >> in it's place [1]. >> >> This patch series represents a first attempt but there are a few >> primary remaining issues that I have yet to address. >> >> A) Removal of debian packing support for the dkms kernel driver >> module. The debian/rules are not well known to me - I've never >> actually made any changes in that area and do not have a >> well formed understanding of how debian packaging works. I wil >> attempt to fix that up in upcoming patch series. >> B) Figuring out how the github workflow - I removed the tests I >> could find that depend on the Linux kernel (i.e. they use >> install_kernel() function. Several other tests are failing >> that would not seem to depend on the Linux kernel. I need to >> read and understand that code better. >> C) There are many Linux specific source modules in the datapath that >> will need eventual removal but some headers are still required for >> the userspace code (which seems counterintuitive but...) >> >> Reviews, suggestions, etc. are appreciated! >> >> 1. https://mail.openvswitch.org/pipermail/ovs-dev/2022-April/393292.html > > I would like to suggest at this time that rather than removing the OVS > Linux kernel path that we "freeze" it at Linux 5.8. This will make it > easier for some consumers of OVS that are continuing to support the > Linux kernel datapath in old distributions. > > The ultimate goal of shifting toward DPDK and AFXDP datapaths is still > preserved but we are placing less burden on some consumers of OVS for > older Linux distributions. > > Perhaps in suggesting removal of the kernel datapath I was being a bit > overly aggressive. > > Thoughts? Concerns? Other suggestions?
Hi. I think we discussed that before. Removal from the master branch doesn't mean that we will stop supporting the kernel module immediately. It will remain in branch 2.17 which will become our new LTS series soon. This branch will be supported until 2025. And we also talked about possibility of extending the support just for a kernel module on that branch, if required. It's not necassary to use the kernel module and OVS form the same branch, obviously. Removal from the master branch will just make it possible to remove the maintenance burden eventually, not right away. And FWIW, the goal is not to force everyone to use userspace datapath, but remove a maintenance burden and push users to use a better supported version of a code. Frankly, we're not doing a great job supporting the out-of-tree module these days. It's getting hard to backport bug fixes. And will be even harder over time since the code drifts away from the version in the upstream kernel. Mainly because we're not backporting new features for a few years already. Does that make sense? > > Thanks, > > - Greg > > >> >> Greg Rose (6): >> acinclude.m4: Remove support for building the OVS kernel module >> rhel: Remove kernel mode spec >> rhel: Remove RHEL 6 kernel module spec >> tests: Remove support for check-kmod test >> Documentation: Remove kernel module documentation >> Disable unsupported kernel builds >> >> .github/workflows/build-and-test.yml | 35 - >> Documentation/faq/releases.rst | 5 +- >> .../contributing/backporting-patches.rst | 7 + >> Documentation/intro/install/fedora.rst | 24 - >> Documentation/intro/install/general.rst | 63 -- >> acinclude.m4 | 683 +----------------- >> rhel/automake.mk | 17 - >> rhel/kmod-openvswitch-rhel6.spec.in | 123 ---- >> rhel/openvswitch-kmod-fedora.spec.in | 152 ---- >> tests/automake.mk | 6 - >> 10 files changed, 11 insertions(+), 1104 deletions(-) >> delete mode 100644 rhel/kmod-openvswitch-rhel6.spec.in >> delete mode 100644 rhel/openvswitch-kmod-fedora.spec.in >> > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
