Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages

[Ilya Maximets <i.maximets@samsung.com>]

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?

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.