[v2,2/2] build: prevent accidentally building without NUMA support

  When libnuma development package is missing on a system, DPDK can still
be built but will be missing much-needed support for NUMA memory
management. This may later cause issues at runtime if the resulting
binary is run on a NUMA system.

We can reduce the incidence of such runtime error by ensuring that, for
native builds*, libnuma is present - unless the user actually specifies
via "max_numa_nodes" that they don't require NUMA support. Having this
as an error condition is also in keeping with what is documented in the
Linux GSG doc, where libnuma is listed as a requirement for building
DPDK [1].

* NOTE: cross-compilation builds have a different logic set, with a
  separate "numa" value indicating if numa support is necessary.

[1] https://doc.dpdk.org/guides-23.03/linux_gsg/sys_reqs.html

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

---
V2: Limit check to linux only
---
 config/meson.build | 9 +++++++++
 1 file changed, 9 insertions(+)
  

On Mon, Jun 12, 2023 at 06:14:56PM +0100, Bruce Richardson wrote:
> When libnuma development package is missing on a system, DPDK can still
> be built but will be missing much-needed support for NUMA memory
> management. This may later cause issues at runtime if the resulting
> binary is run on a NUMA system.
> 
> We can reduce the incidence of such runtime error by ensuring that, for
> native builds*, libnuma is present - unless the user actually specifies
> via "max_numa_nodes" that they don't require NUMA support. Having this
> as an error condition is also in keeping with what is documented in the
> Linux GSG doc, where libnuma is listed as a requirement for building
> DPDK [1].
> 
> * NOTE: cross-compilation builds have a different logic set, with a
>   separate "numa" value indicating if numa support is necessary.
> 
> [1] https://doc.dpdk.org/guides-23.03/linux_gsg/sys_reqs.html
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> ---
> V2: Limit check to linux only
> ---
>  config/meson.build | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
I see this patch has failures reported in the CI, due to some of the
systems not having libnuma installed. I'd view that as a false positive,
since libnuma is effectively a mandatory requirement for building DPDK to
run on most systems. [And this patch still provides a way to build without
it - that way just has to be selected deliberately, rather than it being chosen
by default, without the user being aware of the omission.]

Regards,
/Bruce
  

On Mon, Jun 12, 2023 at 7:59 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Jun 12, 2023 at 06:14:56PM +0100, Bruce Richardson wrote:
> > When libnuma development package is missing on a system, DPDK can still
> > be built but will be missing much-needed support for NUMA memory
> > management. This may later cause issues at runtime if the resulting
> > binary is run on a NUMA system.
> >
> > We can reduce the incidence of such runtime error by ensuring that, for
> > native builds*, libnuma is present - unless the user actually specifies
> > via "max_numa_nodes" that they don't require NUMA support. Having this
> > as an error condition is also in keeping with what is documented in the
> > Linux GSG doc, where libnuma is listed as a requirement for building
> > DPDK [1].
> >
> > * NOTE: cross-compilation builds have a different logic set, with a
> >   separate "numa" value indicating if numa support is necessary.
> >
> > [1] https://doc.dpdk.org/guides-23.03/linux_gsg/sys_reqs.html
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> > ---
> > V2: Limit check to linux only
> > ---
> >  config/meson.build | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> I see this patch has failures reported in the CI, due to some of the
> systems not having libnuma installed. I'd view that as a false positive,
> since libnuma is effectively a mandatory requirement for building DPDK to
> run on most systems. [And this patch still provides a way to build without
> it - that way just has to be selected deliberately, rather than it being chosen
> by default, without the user being aware of the omission.]

The Intel CI lab job failing seems to be an issue in their RHEL 8.7 environment.
Can you ping them to figure it out?


For the i386 job in GHA.. either we install a 32bits numa library, or
we can silence this by setting max_numa_nodes to 1.