Re: [dpdk-dev] RHEL 7 support

[Lance Richardson <lance.richardson@broadcom.com>]

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

On Tue, Jul 13, 2021 at 5:48 AM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 12/07/2021 18:34, Honnappa Nagarahalli wrote:
> > <snip>
> >
> >>
> >> Hi,
> >>
> >> I would like to open a discussion about RHEL 7 support in DPDK.
> >> How long do we want to support it in new DPDK versions?
> >> Can we drop RHEL 7 support starting DPDK 21.11?
> > I think the concerns were from Redhat and Intel.
> >
>
> I think it's fine to drop from a DPDK distro package view. The DPDK
> package in RHEL7 won't be updated to new main releases anymore.
>
> It's not quite as clear for a user compiling their own DPDK. CentOS7 is
> in maintenance mode until mid 2024 and will only get security or
> critical fixes.
>
> You could still have a user on CentOS7 compiling their own DPDK from the
> latest tarballs. It feels like an unlikely combination but maybe someone
> knows of a user like that.
>
> As the distro version won't get latest software packages, it seems
> reasonable that latest DPDK is not supported either, but there would
> need to be some advance warning.
>
> 20.11 LTS will provide bugfix/security that should be ok on CentOS7
> until Jan 2023.
>
> >>
> >> If we decide to drop RHEL 7 support, does it mean we can generally use
> >> standard C11 atomics?
> > What is the next RHEL version we support officially?
>
> RHEL8 is supported.
>
> > If we adopt C11 atomic APIs, we need to think about windows support too.
> >
> >>
> >> What other benefits or impacts can you think about?
> >>
> >
>

Are the issues with continuing to support RHEL 7 all related to the default
gcc version in RHEL 7 (the structure initialization to {0} issue and lack of
<atomic.h> etc. apply to 4.8 but not 4.9+), or are there also lib/kernel issues?

The minimum supported gcc version is already documented to be 4.9+, which
seems to rule out RHEL 7 unless a newer version of gcc is used (which is
easy to do by installing one of the "software collection" toolset packages,
not sure if that is a valid option to suggest).