I’ll set up the CI testing environment on kernel 4.19 as per the current minimum requirement then.
Thanks, Cody Cheng On Sat, Mar 22, 2025 at 9:02 AM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Friday, 21 March 2025 16.53 > > > > On Fri, 21 Mar 2025 07:28:45 +0100 > > Morten Brørup <m...@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:cch...@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. >
