From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) by dpdk.org (Postfix) with ESMTP id 4D9B72BE1 for ; Tue, 10 May 2016 04:10:08 +0200 (CEST) Received: by mail-yw0-f169.google.com with SMTP id o66so305585601ywc.3 for ; Mon, 09 May 2016 19:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8tJrytxQY+vEhjFCZxom7DVaghaPK8/sy1Zuy9C65Pw=; b=gLeujYY9AGSvZmjvDZf7ofmNXazFy2ZMgHRIw5Sh96mntAPciC5HtLbLXqc6zGU9yc xjs7GBX4GvpROH+RkBguYbKIEITPLqwbLMQiLHudj2eDEyNLvJs/FL5e9LYmMBTQByKE b4rEqEB+m2f2o9ht/BC/vR4kXQioGHb/bOYlQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8tJrytxQY+vEhjFCZxom7DVaghaPK8/sy1Zuy9C65Pw=; b=TTNOB6gX2MNS8Pci1ugVKhMc+jZERDHlnxbzQ2PQ6TyDvWiKdoR6G/PElNE/MsyVGh i+g2lAXm95571ZkyGg+oBz5xNap0zJVJ2lVsH+lYqlhhckzyn7zmm/yJRZBO7dUR/vCA JPHHIvQhBHotNylt7mXlWhVpAFvvjhe/6N0c1K8soaHM+cchrpgQJHVK5qdb270t1kJ7 UFw/K7Tvb82Nbnu8O1ofoagdozdrAqPu1PE3/ZgUWFDr8bv9+SqVKvV0uDt50QXEQwHE poY0B0s3DBqSIVJxjQRyjPzQxgc4+aYGE+RdCtVonOFpOpSGee33fHNuMzu4ioa9Wr4C sIQw== X-Gm-Message-State: AOPr4FWFlW2NE+NmqolfYE5hxrzIDuso0AioJAlHT3shYrik/sy2zbzsD9fZvqCK2tC400esNukn8mwiJeoNT0u/ MIME-Version: 1.0 X-Received: by 10.37.194.198 with SMTP id s189mr21712211ybf.100.1462846207716; Mon, 09 May 2016 19:10:07 -0700 (PDT) Received: by 10.37.223.2 with HTTP; Mon, 9 May 2016 19:10:07 -0700 (PDT) In-Reply-To: <20160509161740.GA1853@localhost.localdomain> References: <1462801702-30918-1-git-send-email-hemant.agrawal@nxp.com> <20160509090621.GA4631@localhost.localdomain> <20160509121118.GA8689@localhost.localdomain> <20160509161740.GA1853@localhost.localdomain> Date: Tue, 10 May 2016 10:10:07 +0800 Message-ID: From: Jianbo Liu To: Jerin Jacob Cc: Hemant Agrawal , dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 02:10:08 -0000 On 10 May 2016 at 00:17, Jerin Jacob wrote: > On Mon, May 09, 2016 at 11:22:15PM +0800, Jianbo Liu wrote: >> On 9 May 2016 at 20:11, Jerin Jacob wrote: >> > On Mon, May 09, 2016 at 07:02:36PM +0800, Jianbo Liu wrote: >> >> On 9 May 2016 at 17:06, Jerin Jacob 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 >> >> >> --- > > Snip > >> >> >> +# >> >> >> +# 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. > > IMO, Conflict part comes secondary, It does not even work with upstream kernel. > Why keep the broken configuration? Two main reasons I think it makes > sense to disable > - It is broken, I don't think arm64 kernel developers likes non VFIO approach I don't think DPDK user is kernel developer in most cases. They maybe like the traditional way. > now. So mostly likely it will be broken > - Trying to avoid out of tree patches wherever is possible as > distribution folks like to work with upstream version. Agree. But there is possible that people/company maintain their own kernel tree. > >> I'd rather keep as it is for armv8a defconfig, becasue it's the base, >> any change may affect existing user. > IMO, It makes sense to disable at armv8a defconfig otherwise all armv8 > variants need add CONFIG_RTE_EAL_IGB_UIO=n in all the configs and its > arch specific issue. We don't have to do that. You didn't explictly disable this config in your current defconfig_arm64-thunderx-linuxapp-gcc, but you know which module to bind.