DPDK patches and discussions
 help / color / mirror / Atom feed
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: Fri, 16 Feb 2024 09:29:47 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F223@smartserver.smartshare.dk> (raw)
In-Reply-To: <20240215190501.582b30f8@hermes.local>

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 16 February 2024 04.05
> 
> On Thu, 11 Jan 2024 23:38:07 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > 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.
> 
> There are three issues here:
> 
> 1. Supporting out of date kernel also means supporting out of date
> build environments
>    that maybe missing headers. The recent example was the TAP device
> requiring (or cloning
>    which is worse) the headers to the FLOWER classifier.  If we move
> the kernel version
>    to current LTS, then FLOWER is always present.
> 2. Supporting out of date kernel means more test infrastructure. Some
> CI needs to build
>    test on older environments.
> 3. The place it impacts current CI is the building on CentOS7. CentOS7
> is end of life
>    do we have to keep it? The compiler also lack good C11 support so
> not sure how CI keeps working.
> 
> The way I view it, if you are on an old system, then stick to old DPDK
> LTS version.
> We don't want to here about regressions on end of life systems.

The system requirements in the Getting Started Guide [1] says:

Kernel version >= 4.14
The kernel version required is based on the oldest long term stable kernel available at kernel.org when the DPDK version is in development.
Compatibility for recent distribution kernels will be kept, notably RHEL/CentOS 7.

[1]: https://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#system-software

If we consider it API breakage to change that, we have to wait until the 24.11 release.
For future DPDK LTS releases, we should be more careful about what we claim to support. And again: If we claim to support something, people expect it to be tested in CI.

Disregarding the API breakage by stopping support for a system we claim to support... RHEL7 testing was changed to LTS only [2], that should probably have been applied to CentOS 7 too.

[2]: https://inbox.dpdk.org/dev/CAJvnSUBcq3gznQD4k=krQ+gu2OxTxA2YJBc=J=LtidFXqgg_hg@mail.gmail.com/



  reply	other threads:[~2024-02-16  8:29 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
2024-02-16  3:05           ` Stephen Hemminger
2024-02-16  8:29             ` Morten Brørup [this message]
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=98CBD80474FA8B44BF855DF32C47DC35E9F223@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).