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

20/06/2017 15:58, Ilya Maximets:

On 20.06.2017 16:07, Thomas Monjalon wrote:

quoted

19/06/2017 13:10, Hemant Agrawal:

quoted

quoted

quoted

quoted

On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:

quoted

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.