DPDK patches and discussions
 help / color / mirror / Atom feed
From: Patrick Robb <probb@iol.unh.edu>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Aaron Conole <aconole@redhat.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	dev@dpdk.org
Subject: Re: [PATCH] doc: update minimum Linux kernel version
Date: Thu, 11 Jan 2024 14:50:05 -0500	[thread overview]
Message-ID: <CAJvnSUA7Nz9ZX8EJFKWaVk=A+1_GkDLAMTmXHnvYfQXBNrg9Ow@mail.gmail.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F130@smartserver.smartshare.dk>

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On Thu, Jan 11, 2024 at 2:27 PM Morten Brørup <mb@smartsharesystems.com>
wrote:

> *From:* Patrick Robb [mailto:probb@iol.unh.edu]
> *Sent:* Thursday, 11 January 2024 20.02
>
>
>
> On Thu, Jan 11, 2024 at 4:18 AM Morten Brørup <mb@smartsharesystems.com>
> wrote:
>
>
> I wonder if any automated tests are using this specific kernel version, or
> if we are only testing using the distros' native kernels. @Aaron?
>
>
>
> For UNH, we generally run from the distros' native kernels. Any exceptions
> are not for testing older kernel versions, so we don't have anything
> running from 4.14 in our testing right now.
>
>
>
> If running some automated testing for, say, the minimum supported kernel
> version at any point in time is a value to anyone, certainly they can speak
> up and we can discuss adding that.
>
>
>
>
>
> 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.
>
Well, adding one system which moves with the minimum supported kernel
version probably wouldn't be too onerous, so I will add a ticket noting
this as a community request. On the other hand, one of the reasons we're
moving to running more and more of our testing from containers is so that
we don't have to do as much VM "babysitting" and our testing environment is
more cleanly defined. Obviously that doesn't apply in this case, so we'd
set up a custom VM for this testing job specifically. But, as an LTS kernel
version reaches EOL approximately 1x per year, it shouldn't be too bad.


>
>
> As an appliance vendor, we build our systems from scratch, including the
> bootloader, kernel and file systems. We don’t use any of the distro stuff.
>
> Having information about well tested kernel versions would be helpful when
> choosing kernel version for our appliances. I suppose other appliance
> vendors also use their own hardened/purpose-built kernel versions, and
> would consider this information useful for their decision process too.
>
>
>
Maybe the best thing we can do without a significant overhaul of our
process is to more explicitly display the kernel version for a system when
reporting results. If others chime in and there is big interest here, we
can go further.

[-- Attachment #2: Type: text/html, Size: 5561 bytes --]

  reply	other threads:[~2024-01-11 19:50 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 [this message]
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
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='CAJvnSUA7Nz9ZX8EJFKWaVk=A+1_GkDLAMTmXHnvYfQXBNrg9Ow@mail.gmail.com' \
    --to=probb@iol.unh.edu \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --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).