20/06/2017 15:58, Ilya Maximets: > On 20.06.2017 16:07, Thomas Monjalon wrote: > > 19/06/2017 13:10, Hemant Agrawal: > >>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote: > >>>>>> So, there are 2 option: > >>>>>> > >>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > >>>>>> from the first version of the patch and disable it by default. > >>>>>> > >>>>>> 2. Keep patch as it is now and make everyone install libnuma > >>>>>> for successful build. > >>> > >> +1 for option 1 > >> It will be a issue and undesired dependency for SoCs, not supporting > >> NUMA architecture. > >> > >> It can be added to the config, who desired to use it by default. > > > > Yes I agree, it cannot be a dependency for architectures which > > do not support NUMA. > > Please can we rework the patch so that only one node is assumed > > if NUMA is disabled for the architecture? > > We're still don't have dynamic build time configuration system. > To make get/set_mempolicy work we need to include <numaif.h> > and have libnuma for successful linkage. > This means that the only option to not have libnuma as dependency > is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > as it was in the first version of the patch. > > There is, actually, the third option (besides 2 already described): > > 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > from the first version of the patch and *enable* it by default. > In this case anyone who doesn't want to have libnuma as dependency > will be able to disable the config option manually. > > Thomas, what do you think? Bruce? Sergio?
It should be enabled on x86 and ppc, and disabled in other default configurations (ARM for now). > P.S. We're always able to implement syscall wrappers by hands without any > external dependencies, but I don't think it's a good decision. I agree to use libnuma instead of re-inventing the wheel. Let's just make it optional at build time and fallback on one node if disabled.
