From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Patrick Robb" <probb@iol.unh.edu>,
"Aaron Conole" <aconole@redhat.com>, <dev@dpdk.org>
Subject: RE: [PATCH] doc: update minimum Linux kernel version
Date: Thu, 11 Jan 2024 23:38:07 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F132@smartserver.smartshare.dk> (raw)
In-Reply-To: <20240111115450.3777aea5@hermes.local>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 11 January 2024 20.55
>
> On Thu, 11 Jan 2024 20:26:56 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> >
> >
> > When the documentation specifies a minimum required kernel version,
> it implicitly claims that DPDK works with that kernel version.
> >
> > So we should either test with the specified kernel version (which
> requires significant effort to set up, so I’m not going to ask for
> it!), or add a big fat disclaimer/warning that DPDK is not tested with
> the mentioned kernel version, and list the kernel versions actually
> tested.
>
> It is much less of an issue than it used to be since there should be no
> need for
> DPDK specific kernel components. The kernel API/ABI is stable across
> releases
> (with the notable exception of BPF). Therefore the DPDK kernel version
> dependency
> is much less than it used to be.
That is my experience too.
Your BPF exception is a great example of the Devil being in the details!
Last time we upgraded the kernel version in our appliances (because we needed a feature not available in the old kernel we were using), we ran into two major problems; the first was so bad that we eventually gave up on debugging it and moved on to yet a newer kernel version; the second was a well documented API change, and thus relatively easy to fix (by using the new API instead of the old) once it started causing problems.
I think many hardware appliances (like ours) are using very old kernel versions, mainly for historical reasons.
Jumping ahead to a modern kernel version seems risky, so taking small steps still leaves us on old kernel versions.
There are also build environment issues, i.e. building a certain kernel version only works with certain GCC versions; you cannot build an old kernel version using a new GCC version or vice versa.
And similar dependencies between libc versions and kernel versions.
And root file system dependencies, mainly expectations to what is in /dev and /proc.
And it's not only DPDK itself and DPDK applications that may run into issues when upgrading the kernel version. Any application or library on the system might run into similar or other problems when upgrading to a newer kernel version.
So the easy solution is to simply stick with whatever kernel version was used for the system initially, and never upgrade it. Or only upgrade to a slightly newer version, to keep the knock-on effect at a minimum.
(The distro companies must be putting significant effort into keeping up with new versions of kernels, libraries and applications, to offer new features and ensure system-wide interoperability. The resulting value of this should be appreciated!)
>
> Poking around the source, still see some leftovers.
>
> Like quick assist documentation wanting kernel version for sources?
> Why does QAT depend on kernel source being present. Thats not right.
>
> The other bad spot is the Intel GVE driver reading and passing
> the OS version in. Looks like some host side validation.
>
> Putting OS version anywhere in DPDK is a mistake.
Interesting observations. Again, I agree very much - it is likely to become problematic to maintain and/or use with other OS versions than its developer had originally foreseen.
next prev parent reply other threads:[~2024-01-11 22:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 16:57 Stephen Hemminger
2024-01-11 9:18 ` Morten Brørup
2024-01-11 18:48 ` Aaron Conole
2024-01-11 19:02 ` Patrick Robb
2024-01-11 19:26 ` Morten Brørup
2024-01-11 19:50 ` Patrick Robb
2024-01-11 19:54 ` Stephen Hemminger
2024-01-11 22:38 ` Morten Brørup [this message]
2024-02-16 3:05 ` Stephen Hemminger
2024-02-16 8:29 ` Morten Brørup
2024-02-16 17:22 ` Stephen Hemminger
2024-02-16 17:42 ` Stephen Hemminger
2024-02-17 19:48 ` Patrick Robb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35E9F132@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=probb@iol.unh.edu \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).