d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
24054e3640
numam-dpdk/config/defconfig_arm64-dpaa2-linuxapp-gcc

23 lines
565 B
Plaintext
Raw Normal View History

drivers: use SPDX tag in NXP dpaa2 files Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-12-19 10:14:40 +00:00
# SPDX-License-Identifier: BSD-3-Clause
# Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
# Copyright 2016 NXP
mk: introduce NXP dpaa2 architecture based on armv8-a This patch introduces dpaa2 machine target to address difference in cpu parameter, number of core to 8 and no numa support w.r.t default armv8-a machine Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2016-05-11 13:47:59 +00:00
#
#include "defconfig_arm64-armv8a-linuxapp-gcc"
# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
CONFIG_RTE_MACHINE="dpaa2"
mk: change dpaa2 machine flag to cortex-a72 DPAA2 devices now support cortex-a72. They no longer support a57. Also fp and simd is no more required to be stated explicitly for standard a72 core. Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-05-26 06:51:06 +00:00
CONFIG_RTE_ARCH_ARM_TUNE="cortex-a72"
mk: introduce NXP dpaa2 architecture based on armv8-a This patch introduces dpaa2 machine target to address difference in cpu parameter, number of core to 8 and no numa support w.r.t default armv8-a machine Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2016-05-11 13:47:59 +00:00
config/dpaa2: change max lcores to 16 To support new LX2 series Signed-off-by: Ashish Jain <ashish.jain@nxp.com>
2017-09-16 10:52:23 +00:00
CONFIG_RTE_MAX_LCORE=16
mk: introduce NXP dpaa2 architecture based on armv8-a This patch introduces dpaa2 machine target to address difference in cpu parameter, number of core to 8 and no numa support w.r.t default armv8-a machine Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2016-05-11 13:47:59 +00:00
CONFIG_RTE_MAX_NUMA_NODES=1
config: set cache line as 128B for generic arm64 armv8 implementations may have 64B or 128B cache line. Setting to the maximum available cache line size in generic config to address minimum DMA alignment across all arm64 implementations. Increasing the cacheline size has no negative impact to cache invalidation on systems with a smaller cache line. The need for the minimum DMA alignment has impact on functional aspects of the platform so default config should cater the functional aspects. There is an impact on memory usage with this scheme, but that's not too important for the single image arm64 distribution use case. The arm64 linux kernel followed the similar approach for single arm64 image use case. http://lxr.free-electrons.com/source/arch/arm64/include/asm/cache.h Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Acked-by: Jianbo Liu <jianbo.liu@linaro.org> Acked-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
2017-04-26 16:29:19 +00:00
CONFIG_RTE_CACHE_LINE_SIZE=64
bus/fslmc: introduce fsl-mc bus driver The fslmc bus driver is a rte_bus driver which scans the fsl-mc bus for NXP DPAA2 SoCs. Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-04-11 13:37:08 +00:00
config: reduce DPAA2 mbuf headroom size to 128 Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2018-01-30 15:06:19 +00:00
CONFIG_RTE_PKTMBUF_HEADROOM=128
mempool/dpaa2: add hardware offloaded mempool DPAA2 Hardware Mempool handlers allow enqueue/dequeue from NXP's QBMAN hardware block. CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS is set to 'dpaa2', if the pool is enabled. This memory pool currently supports packet mbuf type blocks only. Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-04-11 13:42:39 +00:00
mem: balanced allocation of hugepages Currently EAL allocates hugepages one by one not paying attention from which NUMA node allocation was done. Such behaviour leads to allocation failure if number of available hugepages for application limited by cgroups or hugetlbfs and memory requested not only from the first socket. Example: # 90 x 1GB hugepages availavle in a system cgcreate -g hugetlb:/test # Limit to 32GB of hugepages cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test # Request 4GB from each of 2 sockets cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ... EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB EAL: 32 not 90 hugepages of size 1024 MB allocated EAL: Not enough memory available on socket 1! Requested: 4096MB, available: 0MB PANIC in rte_eal_init(): Cannot init memory This happens beacause all allocated pages are on socket 0. Fix this issue by setting mempolicy MPOL_PREFERRED for each hugepage to one of requested nodes using following schema: 1) Allocate essential hugepages: 1.1) Allocate as many hugepages from numa N to only fit requested memory for this numa. 1.2) repeat 1.1 for all numa nodes. 2) Try to map all remaining free hugepages in a round-robin fashion. 3) Sort pages and choose the most suitable. In this case all essential memory will be allocated and all remaining pages will be fairly distributed between all requested nodes. New config option RTE_EAL_NUMA_AWARE_HUGEPAGES introduced and enabled by default for linuxapp except armv7 and dpaa2. Enabling of this option adds libnuma as a dependency for EAL. Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages") Signed-off-by: Ilya Maximets <i.maximets@samsung.com> Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
2017-06-29 05:59:19 +00:00
# Doesn't support NUMA
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
config: enable vhost NUMA awareness by default 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.maximets@samsung.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
2017-06-29 05:59:20 +00:00
CONFIG_RTE_LIBRTE_VHOST_NUMA=n
mem: balanced allocation of hugepages Currently EAL allocates hugepages one by one not paying attention from which NUMA node allocation was done. Such behaviour leads to allocation failure if number of available hugepages for application limited by cgroups or hugetlbfs and memory requested not only from the first socket. Example: # 90 x 1GB hugepages availavle in a system cgcreate -g hugetlb:/test # Limit to 32GB of hugepages cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test # Request 4GB from each of 2 sockets cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ... EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB EAL: 32 not 90 hugepages of size 1024 MB allocated EAL: Not enough memory available on socket 1! Requested: 4096MB, available: 0MB PANIC in rte_eal_init(): Cannot init memory This happens beacause all allocated pages are on socket 0. Fix this issue by setting mempolicy MPOL_PREFERRED for each hugepage to one of requested nodes using following schema: 1) Allocate essential hugepages: 1.1) Allocate as many hugepages from numa N to only fit requested memory for this numa. 1.2) repeat 1.1 for all numa nodes. 2) Try to map all remaining free hugepages in a round-robin fashion. 3) Sort pages and choose the most suitable. In this case all essential memory will be allocated and all remaining pages will be fairly distributed between all requested nodes. New config option RTE_EAL_NUMA_AWARE_HUGEPAGES introduced and enabled by default for linuxapp except armv7 and dpaa2. Enabling of this option adds libnuma as a dependency for EAL. Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages") Signed-off-by: Ilya Maximets <i.maximets@samsung.com> Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
2017-06-29 05:59:19 +00:00
config: enable virtual IOVA by default for DPAA2 Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-07-11 14:55:58 +00:00
CONFIG_RTE_LIBRTE_DPAA2_USE_PHYS_IOVA=n
Reference in New Issue Copy Permalink