[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

Jianbo Liu jianbo.liu at linaro.org
Mon May 9 17:22:15 CEST 2016


On 9 May 2016 at 20:11, Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote:
> On Mon, May 09, 2016 at 07:02:36PM +0800, Jianbo Liu wrote:
>> On 9 May 2016 at 17:06, Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote:
>> > On Mon, May 09, 2016 at 07:18:22PM +0530, Hemant Agrawal wrote:
>> >> 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 at nxp.com>
>> >> ---
>> >>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 44 +++++++++++++++++++++++
>> >>  mk/machine/dpaa2/rte.vars.mk              | 60 +++++++++++++++++++++++++++++++
>> >>  mk/rte.module.mk                          |  5 +++
>> >>  3 files changed, 109 insertions(+)
>> >>  create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
>> >>  create mode 100644 mk/machine/dpaa2/rte.vars.mk
>> >>
>> >> diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> >> new file mode 100644
>> >> index 0000000..80bda26
>> >> --- /dev/null
>> >> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> >> @@ -0,0 +1,44 @@
>> >> +#   BSD LICENSE
>> >> +#
>> >> +#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
>> >> +#
>> >> +#   Redistribution and use in source and binary forms, with or without
>> >> +#   modification, are permitted provided that the following conditions
>> >> +#   are met:
>> >> +#
>> >> +#     * Redistributions of source code must retain the above copyright
>> >> +#       notice, this list of conditions and the following disclaimer.
>> >> +#     * Redistributions in binary form must reproduce the above copyright
>> >> +#       notice, this list of conditions and the following disclaimer in
>> >> +#       the documentation and/or other materials provided with the
>> >> +#       distribution.
>> >> +#     * Neither the name of Freescale Semiconductor nor the names of its
>> >> +#       contributors may be used to endorse or promote products derived
>> >> +#       from this software without specific prior written permission.
>> >> +#
>> >> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> >> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> >> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> >> +#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> >> +#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> >> +#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> >> +#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> >> +#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> >> +#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> >> +#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> >> +#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> >> +#
>> >> +
>> >> +#include "defconfig_arm64-armv8a-linuxapp-gcc"
>> >> +
>> >> +# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
>> >> +CONFIG_RTE_MACHINE="dpaa2"
>> >> +CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
>> >> +
>> >> +#
>> >> +# Compile Environment Abstraction Layer
>> >> +#
>> >> +CONFIG_RTE_MAX_LCORE=8
>> >> +CONFIG_RTE_MAX_NUMA_NODES=1
>> >> +CONFIG_RTE_EAL_IGB_UIO=n
>> >
>> > I think it makes sense to move this option to generic arm64 config
>> > as upstream arm64 kernel does not have support for sysfs based PCI mmap
>> > resource file,(/sys/bus/pci/devices/B:D:F/resource[_wc]X) need for
>> > CONFIG_RTE_EAL_IGB_UIO to work) and use VFIO for all cases.
>> >
>> > Any objections?
>> >
>> Is there any conflict to keep both?
>
> I would like to avoid the case like below in dpdk.org ml.
> http://dpdk.org/ml/archives/dev/2016-January/031313.html
>
So no conflict to enable both.
I'd rather keep as it is for armv8a defconfig, becasue it's the base,
any change may affect existing user.


More information about the dev mailing list