DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Cody Cheng" <ccheng@iol.unh.edu>,
	"Kevin Traynor" <ktraynor@redhat.com>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	<techboard@dpdk.org>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"David Marchand" <david.marchand@redhat.com>, <dev@dpdk.org>,
	"Ali Alnubani" <alialnu@nvidia.com>, <galco@nvidia.com>
Subject: RE: Clarification on Minimum Supported Kernel Version for DPDK
Date: Sat, 22 Mar 2025 14:02:25 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9FB3B@smartserver.smartshare.dk> (raw)
In-Reply-To: <20250321085259.095bd234@hermes.local>

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 21 March 2025 16.53
> 
> On Fri, 21 Mar 2025 07:28:45 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > @Kevin, @Stephen, @Bruce,
> >
> > I cannot reliably answer Cody's question, and it may need further
> discussion.
> >
> > What is your opinion on minimum Linux kernel version requirements?
> >
> > @Thomas: In the future, the DPDK release notes should mention the
> minimum Linux kernel requirements.
> >
> > > From: Cody Cheng [mailto:ccheng@iol.unh.edu]
> > > Sent: Thursday, 20 March 2025 21.28
> > >
> > > Hi Morten,
> > >
> > > I am in the process of setting up a test environment at the UNH
> DPDK
> > > Community Test Lab that follows the minimum supported kernel
> version
> > > for DPDK. According to the DPDK documentation, the minimum
> supported
> > > kernel version is 4.19. However, the oldest long term stable kernel
> > > version listed on kernel.org is 5.4.291.
> > >
> > > Should the test environment be set up on kernel version 4.19 or
> > > 5.4.291?
> >
> > The kernel 4.19 support stems from still supporting RHEL/CentOS 7.
> > I wonder if this exception mentioned in the documentation [1] is
> still valid, or if we should bump it to RHEL/CentOS 8, which ships with
> kernel 4.18 [1].
> >
> > RHEL/CentOS 7 support was discussed at by tech board long ago [2],
> but I cannot find a conclusion about the kernel version; the discussion
> was mostly about compiler support.
> >
> > [1]: https://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#system-
> software
> > [2]:
> https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/htm
> l-single/8.0_release_notes/index#overview
> > [3]: https://mails.dpdk.org/archives/dev/2023-February/263516.html
> 
> My opinion has always been that DPDK only offers certain guarantees
> about testing:
>   - oldest current LTS
>   - oldest supported version of Redhat/Ubuntu/SUSE enterprise kernels
> 
> after that in the embedded space, the user is likely to be ok but any
> kernel
> related issues are their problem not the communities to deal with.

Generally, if some new DPDK feature requires a new kernel (or new kernel feature), the details should be mentioned in the release notes.
And preferably, that feature should degrade gracefully when the feature is not present.

For the embedded space, we could support the oldest current version available as Super LTS [4], which is 4.4. And for now, we could stick with the second oldest, 4.19, which is what we currently have.

[4]: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership

Some old kernel version might not be officially supported by the Kernel community, but an embedded vendor might have tested the relevant features extensively and thus trust it more than some new and officially supported version.
So let's not require a newer version than we absolutely must, on technical grounds.
It seems that kernel 4.19 is the current minimum requirement, so let's stick with that, until there are valid technical reasons for requiring a newer version.

Anyway, it seems we need to clarify the policy for kernel version requirements.
It's easy regarding the distros; DPDK running on those require their shipped kernel version, at minimum.
It's for everything else clarification is needed.

And it's not just embedded. Virtual appliances can be tricky too... with our SmartShare VM we had to add support for running as a guest under an ancient QEMU host version, because that is the hypervisor used by one of the big system providers in our most important target market.

In non-cloud market segments, a lot of really old stuff is still being used in production, working perfectly fine.

> 
> The two parts most likely to cause issues are vfio-pci and vhost
> related stuff.
> There is also small chance of issues with the memory handling in EAL.
And maybe handling of many CPU cores, and most likely something related to the new cache steering feature.


      reply	other threads:[~2025-03-22 13:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMEVEZvCoVpMjFpmY29-x0zB2tQvNrJsTacs6-Zzx4jJB_GsoQ@mail.gmail.com>
2025-03-21  6:28 ` Morten Brørup
2025-03-21  8:34   ` Bruce Richardson
2025-03-21 10:42     ` Morten Brørup
2025-03-21 15:52   ` Stephen Hemminger
2025-03-22 13:02     ` Morten Brørup [this message]

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=98CBD80474FA8B44BF855DF32C47DC35E9FB3B@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=alialnu@nvidia.com \
    --cc=bruce.richardson@intel.com \
    --cc=ccheng@iol.unh.edu \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=galco@nvidia.com \
    --cc=ktraynor@redhat.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=stephen@networkplumber.org \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /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).