[v5] build: update DPDK to use C11 standard
Checks
Commit Message
As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.
Forcing use of the C standard, rather than the standard with
GNU extensions, means that some posix definitions which are not in
the C standard are unavailable by default. We fix this by ensuring
the correct defines or cflags are passed to the components that
need them.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
V5:
* Fix build issues with bool type in altivec code, due to bool type
being in C11. Use __bool for altivec-specific version instead.
V4:
* pass cflags to the structure and definition checks in mlx* drivers
to ensure posix definitions - as well as C-standard ones - are
available.
V3:
* remove (now unneeded) use of -std=gnu99 in failsafe net driver.
V2:
* Resubmit now that 23.11-rc0 patch applied
* Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
definition of strerror_r() with c11 standard.
---
doc/guides/linux_gsg/sys_reqs.rst | 3 ++-
doc/guides/rel_notes/deprecation.rst | 18 ------------------
doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
drivers/common/mlx5/linux/meson.build | 5 +++--
drivers/net/failsafe/meson.build | 1 -
drivers/net/mlx4/meson.build | 4 ++--
lib/acl/acl_run_altivec.h | 4 ++--
lib/eal/common/eal_common_errno.c | 1 +
meson.build | 1 +
9 files changed, 28 insertions(+), 26 deletions(-)
Comments
On Wed, Aug 02, 2023 at 01:31:34PM +0100, Bruce Richardson wrote:
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
>
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
> V5:
> * Fix build issues with bool type in altivec code, due to bool type
> being in C11. Use __bool for altivec-specific version instead.
>
Just a note on the altivec builds: from my testing on latest ubuntu with
"powerpc64le-linux-gnu-gcc (Ubuntu 12.3.0-1ubuntu1~23.04)", there are quite
a few warnings/errors building the current DPDK mainline. This patch
doesn't fix any of those errors, but neither does it add any new ones,
as far as I can see! However, we may need some more PPC fixes and updated
CI coverage to catch these issues sooner in future.
/Bruce
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Wednesday, August 2, 2023 3:32 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Morten Brørup
> <mb@smartsharesystems.com>; Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> Subject: [PATCH v5] build: update DPDK to use C11 standard
>
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
>
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
> V5:
> * Fix build issues with bool type in altivec code, due to bool type
> being in C11. Use __bool for altivec-specific version instead.
>
> V4:
> * pass cflags to the structure and definition checks in mlx* drivers
> to ensure posix definitions - as well as C-standard ones - are
> available.
>
> V3:
> * remove (now unneeded) use of -std=gnu99 in failsafe net driver.
>
> V2:
> * Resubmit now that 23.11-rc0 patch applied
> * Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
> definition of strerror_r() with c11 standard.
>
> ---
Tested-by: Ali Alnubani <alialnu@nvidia.com>
Thanks,
Ali
On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
>
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Tested-by: Ali Alnubani <alialnu@nvidia.com>
The CI results look good.
Applied, thanks!
03/08/2023 15:36, David Marchand:
> On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As previously announced, DPDK 23.11 will require a C11 supporting
> > compiler and will use the C11 standard in all builds.
> >
> > Forcing use of the C standard, rather than the standard with
> > GNU extensions, means that some posix definitions which are not in
> > the C standard are unavailable by default. We fix this by ensuring
> > the correct defines or cflags are passed to the components that
> > need them.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Tested-by: Ali Alnubani <alialnu@nvidia.com>
>
> The CI results look good.
>
> Applied, thanks!
The compiler support is updated, that's fine.
Should we go further and document some major Linux distributions?
One concern is to make clear RHEL 7 is not supported anymore.
Should it be a release note?
On Thu, 10 Aug 2023 15:34:43 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> 03/08/2023 15:36, David Marchand:
> > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > compiler and will use the C11 standard in all builds.
> > >
> > > Forcing use of the C standard, rather than the standard with
> > > GNU extensions, means that some posix definitions which are not in
> > > the C standard are unavailable by default. We fix this by ensuring
> > > the correct defines or cflags are passed to the components that
> > > need them.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> >
> > The CI results look good.
> >
> > Applied, thanks!
>
> The compiler support is updated, that's fine.
> Should we go further and document some major Linux distributions?
> One concern is to make clear RHEL 7 is not supported anymore.
> Should it be a release note?
>
>
Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
Also, is it possible to add automated check in build for compiler version?
On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> On Thu, 10 Aug 2023 15:34:43 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 03/08/2023 15:36, David Marchand:
> > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > compiler and will use the C11 standard in all builds.
> > > >
> > > > Forcing use of the C standard, rather than the standard with
> > > > GNU extensions, means that some posix definitions which are not in
> > > > the C standard are unavailable by default. We fix this by ensuring
> > > > the correct defines or cflags are passed to the components that
> > > > need them.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > >
> > > The CI results look good.
> > >
> > > Applied, thanks!
> >
> > The compiler support is updated, that's fine.
> > Should we go further and document some major Linux distributions?
> > One concern is to make clear RHEL 7 is not supported anymore.
> > Should it be a release note?
> >
Well, DPDK currently is still building fine on Centos 7 for me, so let's
hold off on claiming anything until it's definitely broken.
> >
>
> Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> Also, is it possible to add automated check in build for compiler version?
I'd be a little careful about what we claim, and I think current docs are
accurate vs our original plans. What we didn't plan to support was the GCC
and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
for example, the build should be fine on RHEL 7.
Now, though, we are having to re-evaluate our use of stdatomics, which
means we may not actually break RHEL 7 compatibility after all. We'll have
to "watch this space" as the saying goes!
Overall, I think the approach of build-time checks is the best, but not
for specific versions, but instead for capabilities. If/when we add support
for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
initial compiler checks a suitable check for them being present and output
a suitable error if not found.
/Bruce
10/08/2023 18:35, Bruce Richardson:
> On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > On Thu, 10 Aug 2023 15:34:43 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > > 03/08/2023 15:36, David Marchand:
> > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > >
> > > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > > compiler and will use the C11 standard in all builds.
> > > > >
> > > > > Forcing use of the C standard, rather than the standard with
> > > > > GNU extensions, means that some posix definitions which are not in
> > > > > the C standard are unavailable by default. We fix this by ensuring
> > > > > the correct defines or cflags are passed to the components that
> > > > > need them.
> > > > >
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > >
> > > > The CI results look good.
> > > >
> > > > Applied, thanks!
> > >
> > > The compiler support is updated, that's fine.
> > > Should we go further and document some major Linux distributions?
> > > One concern is to make clear RHEL 7 is not supported anymore.
> > > Should it be a release note?
> > >
>
> Well, DPDK currently is still building fine on Centos 7 for me, so let's
> hold off on claiming anything until it's definitely broken.
>
> > >
> >
> > Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> > Also, is it possible to add automated check in build for compiler version?
>
> I'd be a little careful about what we claim, and I think current docs are
> accurate vs our original plans. What we didn't plan to support was the GCC
> and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
> for example, the build should be fine on RHEL 7.
>
> Now, though, we are having to re-evaluate our use of stdatomics, which
> means we may not actually break RHEL 7 compatibility after all. We'll have
> to "watch this space" as the saying goes!
>
> Overall, I think the approach of build-time checks is the best, but not
> for specific versions, but instead for capabilities. If/when we add support
> for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
> initial compiler checks a suitable check for them being present and output
> a suitable error if not found.
OK looks good
On Thu, 10 Aug 2023 18:49:09 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> 10/08/2023 18:35, Bruce Richardson:
> > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 03/08/2023 15:36, David Marchand:
> > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > <bruce.richardson@intel.com> wrote:
> > > > > >
> > > > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > > > compiler and will use the C11 standard in all builds.
> > > > > >
> > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > GNU extensions, means that some posix definitions which are not in
> > > > > > the C standard are unavailable by default. We fix this by ensuring
> > > > > > the correct defines or cflags are passed to the components that
> > > > > > need them.
> > > > > >
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > >
> > > > > The CI results look good.
> > > > >
> > > > > Applied, thanks!
> > > >
> > > > The compiler support is updated, that's fine.
> > > > Should we go further and document some major Linux distributions?
> > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > Should it be a release note?
> > > >
> >
> > Well, DPDK currently is still building fine on Centos 7 for me, so let's
> > hold off on claiming anything until it's definitely broken.
> >
> > > >
> > >
> > > Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> > > Also, is it possible to add automated check in build for compiler version?
> >
> > I'd be a little careful about what we claim, and I think current docs are
> > accurate vs our original plans. What we didn't plan to support was the GCC
> > and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
> > for example, the build should be fine on RHEL 7.
> >
> > Now, though, we are having to re-evaluate our use of stdatomics, which
> > means we may not actually break RHEL 7 compatibility after all. We'll have
> > to "watch this space" as the saying goes!
> >
> > Overall, I think the approach of build-time checks is the best, but not
> > for specific versions, but instead for capabilities. If/when we add support
> > for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
> > initial compiler checks a suitable check for them being present and output
> > a suitable error if not found.
>
> OK looks good
Note: RHEL 7 official end of maintenance support is not until June 2024.
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 10 August 2023 19.03
>
> On Thu, 10 Aug 2023 18:49:09 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 10/08/2023 18:35, Bruce Richardson:
> > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 03/08/2023 15:36, David Marchand:
> > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > >
> > > > > > > As previously announced, DPDK 23.11 will require a C11
> supporting
> > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > >
> > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > GNU extensions, means that some posix definitions which are
> not in
> > > > > > > the C standard are unavailable by default. We fix this by
> ensuring
> > > > > > > the correct defines or cflags are passed to the components
> that
> > > > > > > need them.
> > > > > > >
> > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > >
> > > > > > The CI results look good.
> > > > > >
> > > > > > Applied, thanks!
> > > > >
> > > > > The compiler support is updated, that's fine.
> > > > > Should we go further and document some major Linux distributions?
> > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > Should it be a release note?
> > > > >
> > >
> > > Well, DPDK currently is still building fine on Centos 7 for me, so
> let's
> > > hold off on claiming anything until it's definitely broken.
> > >
> > > > >
> > > >
> > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> notice.
> > > > Also, is it possible to add automated check in build for compiler
> version?
> > >
> > > I'd be a little careful about what we claim, and I think current docs
> are
> > > accurate vs our original plans. What we didn't plan to support was
> the GCC
> > > and Clang compiler versions in RHEL 7, but if one installs an updated
> GCC,
> > > for example, the build should be fine on RHEL 7.
> > >
> > > Now, though, we are having to re-evaluate our use of stdatomics,
> which
> > > means we may not actually break RHEL 7 compatibility after all. We'll
> have
> > > to "watch this space" as the saying goes!
> > >
> > > Overall, I think the approach of build-time checks is the best, but
> not
> > > for specific versions, but instead for capabilities. If/when we add
> support
> > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> the
> > > initial compiler checks a suitable check for them being present and
> output
> > > a suitable error if not found.
Exactly. Capabilities checks is the right way to go when cross compiling.
> >
> > OK looks good
>
> Note: RHEL 7 official end of maintenance support is not until June 2024.
>
It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.
Regardless, I think that DPDK 23.11 support for RHEL 7 should be limited to "might work on RHEL 7", rather than guaranteed support for RHEL 7 (which would require DPDK CI to resume testing on RHEL 7).
IIRC, there was also the argument that DPDK 23.11 LTS support ends after June 2024.
Here's another argument for abandoning RHEL 7: RHEL 7 uses Linux Kernel 3.10. Although DPDK requires Linux Kernel >= 4.14, we promise backwards compatibility for RHEL/CentOS 7. Do we really still want to do that? (Note: RHEL 8 uses Linux Kernel 4.18.)
While we're discussing the Linux Kernel version required... Is it documented anywhere why a specific Linux Kernel version is required by DPDK? Or more specifically: Is it documented anywhere which DPDK features require which specific Linux Kernel versions?
On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 10 August 2023 19.03
> >
> > On Thu, 10 Aug 2023 18:49:09 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > > 10/08/2023 18:35, Bruce Richardson:
> > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > >
> > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > >
> > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > supporting
> > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > >
> > > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > > GNU extensions, means that some posix definitions which are
> > not in
> > > > > > > > the C standard are unavailable by default. We fix this by
> > ensuring
> > > > > > > > the correct defines or cflags are passed to the components
> > that
> > > > > > > > need them.
> > > > > > > >
> > > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > >
> > > > > > > The CI results look good.
> > > > > > >
> > > > > > > Applied, thanks!
> > > > > >
> > > > > > The compiler support is updated, that's fine.
> > > > > > Should we go further and document some major Linux distributions?
> > > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > > Should it be a release note?
> > > > > >
> > > >
> > > > Well, DPDK currently is still building fine on Centos 7 for me, so
> > let's
> > > > hold off on claiming anything until it's definitely broken.
> > > >
> > > > > >
> > > > >
> > > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> > notice.
> > > > > Also, is it possible to add automated check in build for compiler
> > version?
> > > >
> > > > I'd be a little careful about what we claim, and I think current docs
> > are
> > > > accurate vs our original plans. What we didn't plan to support was
> > the GCC
> > > > and Clang compiler versions in RHEL 7, but if one installs an updated
> > GCC,
> > > > for example, the build should be fine on RHEL 7.
> > > >
> > > > Now, though, we are having to re-evaluate our use of stdatomics,
> > which
> > > > means we may not actually break RHEL 7 compatibility after all. We'll
> > have
> > > > to "watch this space" as the saying goes!
> > > >
> > > > Overall, I think the approach of build-time checks is the best, but
> > not
> > > > for specific versions, but instead for capabilities. If/when we add
> > support
> > > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> > the
> > > > initial compiler checks a suitable check for them being present and
> > output
> > > > a suitable error if not found.
>
> Exactly. Capabilities checks is the right way to go when cross compiling.
>
> > >
> > > OK looks good
> >
> > Note: RHEL 7 official end of maintenance support is not until June 2024.
> >
>
> It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.
we would substantially reduce porting delta to retain C11, there are a
number of other things that help with portability from C11 that we can
utilized that i hadn't brought up before since it had been resolved to
adopt it.
it would be really unfortunate to say we aren't going to require C11
since that would cause me to have to bring a lot more conditional
compile into the tree.
just fyi
>
> Regardless, I think that DPDK 23.11 support for RHEL 7 should be limited to "might work on RHEL 7", rather than guaranteed support for RHEL 7 (which would require DPDK CI to resume testing on RHEL 7).
>
> IIRC, there was also the argument that DPDK 23.11 LTS support ends after June 2024.
>
> Here's another argument for abandoning RHEL 7: RHEL 7 uses Linux Kernel 3.10. Although DPDK requires Linux Kernel >= 4.14, we promise backwards compatibility for RHEL/CentOS 7. Do we really still want to do that? (Note: RHEL 8 uses Linux Kernel 4.18.)
>
> While we're discussing the Linux Kernel version required... Is it documented anywhere why a specific Linux Kernel version is required by DPDK? Or more specifically: Is it documented anywhere which DPDK features require which specific Linux Kernel versions?
>
On Thu, Aug 10, 2023 at 03:34:43PM -0700, Tyler Retzlaff wrote:
> On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, 10 August 2023 19.03
> > >
> > > On Thu, 10 Aug 2023 18:49:09 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 10/08/2023 18:35, Bruce Richardson:
> > > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > >
> > > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > > >
> > > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > > supporting
> > > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > > >
> > > > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > > > GNU extensions, means that some posix definitions which are
> > > not in
> > > > > > > > > the C standard are unavailable by default. We fix this by
> > > ensuring
> > > > > > > > > the correct defines or cflags are passed to the components
> > > that
> > > > > > > > > need them.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > > >
> > > > > > > > The CI results look good.
> > > > > > > >
> > > > > > > > Applied, thanks!
> > > > > > >
> > > > > > > The compiler support is updated, that's fine.
> > > > > > > Should we go further and document some major Linux distributions?
> > > > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > > > Should it be a release note?
> > > > > > >
> > > > >
> > > > > Well, DPDK currently is still building fine on Centos 7 for me, so
> > > let's
> > > > > hold off on claiming anything until it's definitely broken.
> > > > >
> > > > > > >
> > > > > >
> > > > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> > > notice.
> > > > > > Also, is it possible to add automated check in build for compiler
> > > version?
> > > > >
> > > > > I'd be a little careful about what we claim, and I think current docs
> > > are
> > > > > accurate vs our original plans. What we didn't plan to support was
> > > the GCC
> > > > > and Clang compiler versions in RHEL 7, but if one installs an updated
> > > GCC,
> > > > > for example, the build should be fine on RHEL 7.
> > > > >
> > > > > Now, though, we are having to re-evaluate our use of stdatomics,
> > > which
> > > > > means we may not actually break RHEL 7 compatibility after all. We'll
> > > have
> > > > > to "watch this space" as the saying goes!
> > > > >
> > > > > Overall, I think the approach of build-time checks is the best, but
> > > not
> > > > > for specific versions, but instead for capabilities. If/when we add
> > > support
> > > > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> > > the
> > > > > initial compiler checks a suitable check for them being present and
> > > output
> > > > > a suitable error if not found.
> >
> > Exactly. Capabilities checks is the right way to go when cross compiling.
> >
> > > >
> > > > OK looks good
> > >
> > > Note: RHEL 7 official end of maintenance support is not until June 2024.
> > >
> >
> > It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.
>
> we would substantially reduce porting delta to retain C11, there are a
> number of other things that help with portability from C11 that we can
> utilized that i hadn't brought up before since it had been resolved to
> adopt it.
>
> it would be really unfortunate to say we aren't going to require C11
> since that would cause me to have to bring a lot more conditional
> compile into the tree.
>
> just fyi
>
As far as I know we are requiring C11, and the meson.build file on main
tree currently has set the minimum for that. We just haven't got code in
there yet that uses the C11 atomics, which is the bit that is missing from
the RHEL 7 compiler.
I agree that we should not actually actively support RHEL 7 - I just
wouldn't call attention to the fact that it's no longer supported if it
still happens to work. Once we actually break it, I'm all for documenting
that it's not supported. [NOTE: I both cases, I'm not saying that we call
it out explicitly as supported either - I'm just talking about a release
note entry saying the opposite!]
/Bruce
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 11 August 2023 10.53
>
> On Thu, Aug 10, 2023 at 03:34:43PM -0700, Tyler Retzlaff wrote:
> > On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Thursday, 10 August 2023 19.03
> > > >
> > > > On Thu, 10 Aug 2023 18:49:09 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 10/08/2023 18:35, Bruce Richardson:
> > > > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger
> wrote:
> > > > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > >
> > > > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > > > >
> > > > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > > > supporting
> > > > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > > > >
> > > > > > > > > > Forcing use of the C standard, rather than the
> standard with
> > > > > > > > > > GNU extensions, means that some posix definitions
> which are
> > > > not in
> > > > > > > > > > the C standard are unavailable by default. We fix this
> by
> > > > ensuring
> > > > > > > > > > the correct defines or cflags are passed to the
> components
> > > > that
> > > > > > > > > > need them.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Bruce Richardson
> <bruce.richardson@intel.com>
> > > > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > Acked-by: Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> > > > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > > > >
> > > > > > > > > The CI results look good.
> > > > > > > > >
> > > > > > > > > Applied, thanks!
> > > > > > > >
> > > > > > > > The compiler support is updated, that's fine.
> > > > > > > > Should we go further and document some major Linux
> distributions?
> > > > > > > > One concern is to make clear RHEL 7 is not supported
> anymore.
> > > > > > > > Should it be a release note?
> > > > > > > >
> > > > > >
> > > > > > Well, DPDK currently is still building fine on Centos 7 for
> me, so
> > > > let's
> > > > > > hold off on claiming anything until it's definitely broken.
> > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Should be addressed in linux/sys_reqs.rst as well as
> deprecation
> > > > notice.
> > > > > > > Also, is it possible to add automated check in build for
> compiler
> > > > version?
> > > > > >
> > > > > > I'd be a little careful about what we claim, and I think
> current docs
> > > > are
> > > > > > accurate vs our original plans. What we didn't plan to support
> was
> > > > the GCC
> > > > > > and Clang compiler versions in RHEL 7, but if one installs an
> updated
> > > > GCC,
> > > > > > for example, the build should be fine on RHEL 7.
> > > > > >
> > > > > > Now, though, we are having to re-evaluate our use of
> stdatomics,
> > > > which
> > > > > > means we may not actually break RHEL 7 compatibility after
> all. We'll
> > > > have
> > > > > > to "watch this space" as the saying goes!
> > > > > >
> > > > > > Overall, I think the approach of build-time checks is the
> best, but
> > > > not
> > > > > > for specific versions, but instead for capabilities. If/when
> we add
> > > > support
> > > > > > for stdatomics to DPDK builds on Linux/BSD, at that point we
> put in
> > > > the
> > > > > > initial compiler checks a suitable check for them being
> present and
> > > > output
> > > > > > a suitable error if not found.
> > >
> > > Exactly. Capabilities checks is the right way to go when cross
> compiling.
> > >
> > > > >
> > > > > OK looks good
> > > >
> > > > Note: RHEL 7 official end of maintenance support is not until June
> 2024.
> > > >
> > >
> > > It was agreed to abandon RHEL 7, mainly driven by the need for C11
> stdatomic.h, which is not supported by the GCC C compiler included with
> RHEL 7. So it pains me to admit that Stephen has a valid point here,
> after it turned out that the GCC g++ is not C11 compatible.
> >
> > we would substantially reduce porting delta to retain C11, there are a
> > number of other things that help with portability from C11 that we can
> > utilized that i hadn't brought up before since it had been resolved to
> > adopt it.
> >
> > it would be really unfortunate to say we aren't going to require C11
> > since that would cause me to have to bring a lot more conditional
> > compile into the tree.
> >
> > just fyi
> >
> As far as I know we are requiring C11, and the meson.build file on main
> tree currently has set the minimum for that. We just haven't got code in
> there yet that uses the C11 atomics, which is the bit that is missing
> from
> the RHEL 7 compiler.
>
> I agree that we should not actually actively support RHEL 7 - I just
> wouldn't call attention to the fact that it's no longer supported if it
> still happens to work. Once we actually break it, I'm all for
> documenting
> that it's not supported. [NOTE: I both cases, I'm not saying that we
> call
> it out explicitly as supported either - I'm just talking about a release
> note entry saying the opposite!]
If I was using RHEL 7, and DPDK degraded the RHEL 7 support level (e.g. not testing it in CI anymore) with a release, I would certainly want this to be highlighted in the release notes! "Not known to be broken, might work" and "passed validation" are two very different things in a production environment. :-)
Anyway, Bruce's point is valid; it's not binary, so let's not scare RHEL 7 users more than we have to.
>
> /Bruce
@@ -27,7 +27,8 @@ Compilation of the DPDK
The setup commands and installed packages needed on various systems may be different.
For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
-* General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+* General development tools including a C compiler supporting the C11 standard,
+ including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
* For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
Deprecation Notices
-------------------
-* C Compiler: From DPDK 23.11 onwards,
- building DPDK will require a C compiler which supports the C11 standard,
- including support for C11 standard atomics.
-
- More specifically, the requirements will be:
-
- * Support for flag "-std=c11" (or similar)
- * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
- Please note:
-
- * C11, including standard atomics, is supported from GCC version 5 onwards,
- and is the default language version in that release
- (Ref: https://gcc.gnu.org/gcc-5/changes.html)
- * C11 is the default compilation mode in Clang from version 3.6,
- which also added support for standard atomics
- (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
* build: Enabling deprecated libraries (``flow_classify``, ``kni``)
won't be possible anymore through the use of the ``disable_libs`` build option.
A new build option for deprecated libraries will be introduced instead.
@@ -20,6 +20,23 @@ DPDK Release 23.11
ninja -C build doc
xdg-open build/doc/guides/html/rel_notes/release_23_11.html
+* Build Requirements: From DPDK 23.11 onwards,
+ building DPDK will require a C compiler which supports the C11 standard,
+ including support for C11 standard atomics.
+
+ More specifically, the requirements will be:
+
+ * Support for flag "-std=c11" (or similar)
+ * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+ Please note:
+
+ * C11, including standard atomics, is supported from GCC version 5 onwards,
+ and is the default language version in that release
+ (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+ * C11 is the default compilation mode in Clang from version 3.6,
+ which also added support for standard atomics
+ (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
New Features
------------
@@ -231,11 +231,12 @@ if libmtcr_ul_found
endif
foreach arg:has_sym_args
- mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs))
+ mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs, args: cflags))
endforeach
foreach arg:has_member_args
file_prefix = '#include <' + arg[1] + '>'
- mlx5_config.set(arg[0], cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs))
+ mlx5_config.set(arg[0],
+ cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs, args: cflags))
endforeach
# Build Glue Library
@@ -7,7 +7,6 @@ if is_windows
subdir_done()
endif
-cflags += '-std=gnu99'
cflags += '-D_DEFAULT_SOURCE'
cflags += '-D_XOPEN_SOURCE=700'
cflags += '-pedantic'
@@ -103,12 +103,12 @@ has_sym_args = [
config = configuration_data()
foreach arg:has_sym_args
config.set(arg[0], cc.has_header_symbol(arg[1], arg[2],
- dependencies: libs))
+ dependencies: libs, args: cflags))
endforeach
foreach arg:has_member_args
file_prefix = '#include <' + arg[1] + '>'
config.set(arg[0], cc.has_member(arg[2], arg[3],
- prefix: file_prefix, dependencies: libs))
+ prefix: file_prefix, dependencies: libs, args: cflags))
endforeach
configure_file(output : 'mlx4_autoconf.h', configuration : config)
@@ -41,7 +41,7 @@ resolve_priority_altivec(uint64_t transition, int n,
{
uint32_t x;
xmm_t results, priority, results1, priority1;
- __vector bool int selector;
+ __vector __bool int selector;
xmm_t *saved_results, *saved_priority;
for (x = 0; x < categories; x += RTE_ACL_RESULTS_MULTIPLIER) {
@@ -110,7 +110,7 @@ transition4(xmm_t next_input, const uint64_t *trans,
xmm_t in, node_type, r, t;
xmm_t dfa_ofs, quad_ofs;
xmm_t *index_mask, *tp;
- __vector bool int dfa_msk;
+ __vector __bool int dfa_msk;
__vector signed char zeroes = {};
union {
uint64_t d64[2];
@@ -4,6 +4,7 @@
/* Use XSI-compliant portable version of strerror_r() */
#undef _GNU_SOURCE
+#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <string.h>
@@ -9,6 +9,7 @@ project('DPDK', 'c',
license: 'BSD',
default_options: [
'buildtype=release',
+ 'c_std=c11',
'default_library=static',
'warning_level=2',
],