On 6/27/2017 3:29 PM, Jerin Jacob wrote:
-----Original Message-----
Date: Tue, 27 Jun 2017 15:11:07 +0530
From: Hemant Agrawal <hemant.agra...@nxp.com>
To: Thomas Monjalon <tho...@monjalon.net>
CC: Ilya Maximets <i.maxim...@samsung.com>, dev@dpdk.org, David Marchand
<david.march...@6wind.com>, Sergio Gonzalez Monroy
<sergio.gonzalez.mon...@intel.com>, Heetae Ahn <heetae82....@samsung.com>,
Yuanhan Liu <y...@fridaylinux.org>, Jianfeng Tan <jianfeng....@intel.com>,
Neil Horman <nhor...@tuxdriver.com>, Yulong Pei <yulong....@intel.com>,
Bruce Richardson <bruce.richard...@intel.com>, Jerin Jacob
<jerin.ja...@caviumnetworks.com>
Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
On 6/27/2017 2:51 PM, Thomas Monjalon wrote:
27/06/2017 11:18, Hemant Agrawal:
On 6/27/2017 2:16 PM, Ilya Maximets wrote:
It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.
Signed-off-by: Ilya Maximets <i.maxim...@samsung.com>
---
config/common_linuxapp | 1 +
config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
3 files changed, 3 insertions(+)
[...]
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
# Doesn't support NUMA
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
#
# Compile Support Libraries for DPAA2
-1
It should also be disabled for generic ARM64. This patch is breaking
generic arm64 config tests on our platforms and creating a unnecessary
dependency.
What do you mean? Which ARM64 platform is it breaking?
We can specifically disable it on more platforms.
Unlike x86, ARM only represent a core architecture.
Different platforms can integrate these cores differently in their SoCs.
The stock ARM v8 cores do not provide support for NUMA in my knowledge.
A72 is just _an_ implementation of armv8. Not ARMv8 specification
itself. By specification it is NUMA capable and there are NUMA
implementation too.
Some vendors have modified ARM cores (e.g. Cavium) to support NUMA
architecture. However that is not a common phenomena.
NUMA config should not be default for generic ARM config. It should be
enabled only for architecture supporting it.
It just an build time dependency. Right? If you feed the libnuma package,
it will NON NUMA as well. Right? ARM64 libnuma package is already
available for major distributions.
yes, libnuma will work for non-NUMA.
My point is, I don't want to make arm64 generic config an exceptional case,
If DPDK common config creates libnuma dependency then there is no reason
for arm64 not have it. It is same for x86 and powerpc, non numa systems
too. Right?
x86 and powerpc configs are single vendor based.
Common should be common and generic.
Why to create a unnecessary dependency, when we know that the support is
not uniform? It adds difficulties e.g. For the ARM cross compilation,
will also have to cross compile libnuma-dev. Makefile will need a path
for specifying the lib and include paths for libnuma and numa.h.
So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors
include NXP. e.g. We use this config on several of our low end systems
(non-dpaa). Also, we use it when running in VM with virtio interfaces on all
of our different platforms (non-dpaa, dpaa1, dpaa2 etc).
On the same note, arm64-armv8a-linuxapp-gcc used by other vendors for Server
machines
with NUMA and if want to keep creating new targets there is no end to it.
How hard is to install libnuma on VM? There is already package for it.
