On 27/03/2025 07:55, Morten Brørup wrote: > + Red Hat tech board members > >> From: Stephen Hemminger [mailto:step...@networkplumber.org] >> Sent: Wednesday, 26 March 2025 20.21 >> >> On Wed, 26 Mar 2025 19:06:58 +0100 >> Morten Brørup <m...@smartsharesystems.com> wrote: >> >>>> From: Bruce Richardson [mailto:bruce.richard...@intel.com] >>>> Sent: Wednesday, 26 March 2025 17.22 >>>> >>>> On Tue, Mar 25, 2025 at 05:22:15PM +0000, Bruce Richardson wrote: >>>>> When doing a build for a target that already has the instruction >> sets >>>>> for AVX2/AVX512 enabled, skip emitting the AVX compiler flags, or >> the >>>>> skylake-avx512 '-march' flags, as they are unnecessary. Instead, >> when >>>>> the default flags produce the desired output, just use them >>>> unmodified. >>>>> >>>>> Depends-on: series-34915 ("remove component-specific logic for >> AVX >>>> builds") >>>>> >>>>> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> >>>>> --- >>>>> >>>>> This patchset depends on the previous AVX rework. However, >> sending it >>>>> separately as a new RFC because it effectively increases the >> minimum >>>>> compiler versions needed for x86 builds - from GCC 5 to 6, and >>>>> Clang 3.6 to 3.9. >>>>> >>>>> For now, I've just documented that as an additional note in the >> GSG >>>> that >>>>> these versions are recommended, but it would be simpler if we >> could >>>> just >>>>> set them as the required minimum baseline (at least in the docs). >>>>> >>>>> Feedback on these compiler version requirements welcome. >>>>> >>>> >>>> +techboard >>>> >>>> Ping for a little bit of feedback for this. Are we ok to bump the >>>> minimum >>>> compiler versions as described above, or will I continue with the >>>> approach >>>> in this RFC of keeping the minimum and just recommending the higher >>>> versions for x86 platforms? >>>> >>>> For reference GCC 6.1 was released April 2016[1], and, Clang 3.9 >> was >>>> released Sept 2016[2] >>>> >>>> /Bruce >>>> >>>> [1] https://gcc.gnu.org/gcc-6/ >>>> [2] https://releases.llvm.org/ >>> >>> Considering GCC versions shipped with RHEL [3]... >>> We kind of support RHEL 7, but we already require a newer compiler >> (GCC 5) than shipped with RHEL 7 (GCC 4.8). >>> RHEL 8 ships with GCC 8, which was released in May 2018 [4]. Maybe we >> can jump to GCC 8? >>> >>> BTW, we should also apply the same principle I argued [5] should >> apply for upgrading the Kernel requirements: There should be a need for >> specific feature or similar - which there is with your patch - and the >> details should be mentioned in the release notes. >>> >>> [3]: https://access.redhat.com/solutions/19458 >>> [4]: https://gcc.gnu.org/gcc-8/ >>> [5]: >> https://inbox.dpdk.org/dev/CAMEVEZutf4sJ=EQFONw_bJW0tGTWqTbF_Tk_y38qzBL >> ccco...@mail.gmail.com/T/#me7c8f1dbe4331ccf232d43512d6ddb51458c568a >>> >> >> RHEL 7 reached end of life on June 30, 2024. >> DPDK need no longer support it on future versions. > > CentOS 7 reached EOL June 2024, yes. > RHEL 7 reached End of Maintenance June 2024, but RHEL 7 Extended Life Cycle > Support is available until June 2028 [6]. > > Although RHEL 7 not fully EOL, I would consider "End Of Maintenance" > sufficiently dead for future DPDK versions not needing to support it. > If you are running a production system on a distro that's on Extended Life > Cycle Support, you shouldn't deploy a new DPDK version - and if you do > anyway, it's your own problem, not the DPDK community's problem. > @Aaron, @Kevin, @Maxime - speak up if you disagree! >
+1 Red Hat will not release new RHEL 7 DPDK packages now and there are no new features/versions of RHEL 7. I agree if anyone is running RHEL(/CentOS) 7 at this point, they should not expect that they can just use new versions of DPDK on it without having to resolve the dependencies themselves. > > [6]: > https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhel-7-end-of-maintenance >
