On 20/06/2017 15:35, Thomas Monjalon wrote:
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?
Ilya, I missed that libnuma is not supported on ARM.
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).
Agree.
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.
That is the simple way out.
Sergio
