From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DD1EC43896; Thu, 11 Jan 2024 20:50:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 684CA40269; Thu, 11 Jan 2024 20:50:19 +0100 (CET) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by mails.dpdk.org (Postfix) with ESMTP id 9AA0340266 for ; Thu, 11 Jan 2024 20:50:17 +0100 (CET) Received: by mail-oi1-f182.google.com with SMTP id 5614622812f47-3bbd1f9e0b8so4653560b6e.0 for ; Thu, 11 Jan 2024 11:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1705002616; x=1705607416; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4pGhRDlgVjEuYrV4LZnmFSRRMHAz1UD8AeUQM3XaPho=; b=YOhLCc4iaHnoyOoXAmU7S9j3fdVf9xqBB9uy9KsV5J51YQ/M2J+Kr/b1jtgjqCN4t0 DZUfHEooFJKgM5olgS5sjcyHtjW98URHab6G3hxD2+Gpu/GoGDX208tiMWxvwrl4i1Zm GqFwgiaSCVmkgHSAyv1yePuhMFCCzJ7BLigSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705002616; x=1705607416; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4pGhRDlgVjEuYrV4LZnmFSRRMHAz1UD8AeUQM3XaPho=; b=O8l3vMbUI2HUExeQdboA154+b6H5nqVnt7ikzSHOZ4qIO8AW4VKJwvIsLoWpfivRwL /uZApgvGQTmwgF6Y/bbBvK5736MtwCeHp0MV/vwqadDE83RF9cp+lNNAYLeqUwfyapja uW+z/FDuUdBgQl2QZdpat6xsFgc44Axe0Sc7xcvM29Q1fYM+XbsJU1AVR1NbCraYRQN8 FiX06ljuMm0KU+sqmUK6QPNkISEzMjMA5eZC31t+Goh4wOY2l04MbsD4eaawyY1NFus9 rE/qk1leGFA9BxlTh5BdJNBIPcvE9Q1deUjtxhET7TiYlOgBtZ4tu7HbJv12StfuO4Bd Msgg== X-Gm-Message-State: AOJu0YynQsdQxU+SBQ0T+9Hg2waQsvobqhynNEYmtGOk4OsiRcmP0sJy VtIlYfUyBSZ/5LhjRXFTAS4Wq394GTRQlPg472/eCtdV5VgNag== X-Google-Smtp-Source: AGHT+IGbcTgVMzZx6Fqn2WlHiI3SZLhwFfSr3tIHUT8ltJw9lD+PeQz+fm8YTnns3DBNRWnpQC5GVmrzkvOoF0RlKwM= X-Received: by 2002:a05:6808:4d0:b0:3bb:d118:ff55 with SMTP id a16-20020a05680804d000b003bbd118ff55mr173520oie.115.1705002616720; Thu, 11 Jan 2024 11:50:16 -0800 (PST) MIME-Version: 1.0 References: <20240110165751.26569-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35E9F124@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F130@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F130@smartserver.smartshare.dk> From: Patrick Robb Date: Thu, 11 Jan 2024 14:50:05 -0500 Message-ID: Subject: Re: [PATCH] doc: update minimum Linux kernel version To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Aaron Conole , Stephen Hemminger , dev@dpdk.org Content-Type: multipart/alternative; boundary="0000000000004fa5fb060eb0dbe6" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000004fa5fb060eb0dbe6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2024 at 2:27=E2=80=AFPM Morten Br=C3=B8rup wrote: > *From:* Patrick Robb [mailto:probb@iol.unh.edu] > *Sent:* Thursday, 11 January 2024 20.02 > > > > On Thu, Jan 11, 2024 at 4:18=E2=80=AFAM Morten Br=C3=B8rup > wrote: > > > I wonder if any automated tests are using this specific kernel version, o= r > if we are only testing using the distros' native kernels. @Aaron? > > > > For UNH, we generally run from the distros' native kernels. Any exception= s > 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 spe= ak > 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 require= s > significant effort to set up, so I=E2=80=99m not going to ask for it!), o= r 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=E2=80=99t use any of the dist= ro stuff. > > Having information about well tested kernel versions would be helpful whe= n > 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. --0000000000004fa5fb060eb0dbe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jan 11, 2024 at 2:27=E2=80=AFPM M= orten Br=C3=B8rup <mb@smarts= haresystems.com> wrote:

From: Patrick Robb [mail= to:probb@iol.unh.edu= ]
Sent: Thursday, 11 January 2024 20.02

=C2=A0

=

On Thu, Jan 11, 2024 at 4:18=E2=80=AFAM Mo= rten Br=C3=B8rup <mb@smartsharesystems.com> wrote:


I wonder if any automated tes= ts are using this specific kernel version, or if we are only testing using = the distros' native kernels. @Aaron?

=C2=A0

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.=C2=A0

=C2=A0

If running some automated testing for, say, the minimum s= upported kernel version at any point in time is a value to anyone, certainl= y they can speak up and we can discuss adding that.=C2=A0=C2=A0

=C2=A0

=C2=A0

When the documentation specifies a minimum required kernel version= , it implicitly claims that DPDK works with that kernel version.<= /u>

So we should eithe= r test with the specified kernel version (which requires significant effort= to set up, so I=E2=80=99m not going to ask for it!), or add a big fat disc= laimer/warning that DPDK is not tested with the mentioned kernel version, a= nd list the kernel versions actually tested.

Well, adding one system which moves with = the minimum supported=C2=A0kernel version probably wouldn't be too oner= ous, so I will=C2=A0add a ticket noting this as a community request. On the= other hand, one of the reasons we're moving to running more and more o= f our testing from containers is so that we don't have to do as much VM= "babysitting" and our testing environment is more cleanly define= d. Obviously that doesn't apply in this case, so we'd set up a cust= om VM for this testing job specifically. But, as an LTS kernel version reac= hes EOL approximately 1x per year, it shouldn't be too bad.=C2=A0
=
=C2=A0
=

=C2=A0

As an appliance vendor, we build ou= r systems from scratch, including the bootloader, kernel and file systems. = We don=E2=80=99t use any of the distro stuff.

Having information about well tested = kernel versions would be helpful when choosing kernel version for our appli= ances. I suppose other appliance vendors also use their own hardened/purpos= e-built kernel versions, and would consider this information useful for the= ir decision process too.

=C2=A0

Maybe the best thing we can do without a s= ignificant 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.
--0000000000004fa5fb060eb0dbe6--