On 5/31/2022 12:22 PM, Frode Nordahl wrote:
On Tue, May 31, 2022 at 7:05 PM Ilya Maximets <[email protected]> wrote:
On 5/31/22 17:36, Gregory Rose wrote:
On 5/25/2022 6:47 AM, Flavio Leitner wrote:
Hi Greg,
On Mon, May 23, 2022 at 09:10:36PM +0200, Ilya Maximets wrote:
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?
Any thoughts on this? The freeze time is approaching, so it would
be great to know your plans for this patch set.
Thanks,
fbl
Hi Flavio and Ilya,
I'll go ahead with the plans as per previous agreements - having issues
with removing the debian kernel module support since I have never
worked on debian rules type make environments. I seem to break
something with every attempt but I will keep at it.
What's my time frame before the freeze?
The "soft-freeze" supposed to be on July 1st. The branch creation
for a new release - mid July. It would be great if we can get this
in before the soft freeze, but branching point is also fine.
So, we have about 6 weeks.
If you can think of any part of the work that can be done separately
by someone else, we could try and find someone to help you out. I'm
not sure if we have experts on debian packaging though. Maybe we
can ask some folks from Canonical. They do their own packaging, but
should know a thing or two about packaging in general.
We'd be happy to help out with the packaging bits.
Both Debian and Ubuntu have drifted away from what is currently in the
debian/ folder in the OVS and OVN repositories. This state is
problematic because from time to time someone tries to build packages
from the OVS/OVN debian package source and then expect that package to
work with up-/down-grades from-/to/ distro versions.
So we would prefer to either remove what's there and replace it with a
README pointing to Debian and Ubuntu package sources, or update what's
there to match packaging state du jour.
I'm fine with either solution but someone else would have to update the
debian packaging. If just removing then I could do that and then update
the documentation.
I'll wait to see what the consensus is.
Thanks,
- Greg
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
