On Thu, 11 Jan 2024 23:38:07 +0100 Morten Brørup <m...@smartsharesystems.com> wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Thursday, 11 January 2024 20.55 > > > > On Thu, 11 Jan 2024 20:26:56 +0100 > > Morten Brørup <m...@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.
