From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2] mempool/dpaa2: add DPAA2 hardware offloaded mempool Date: Tue, 11 Apr 2017 14:50:14 +0200 Message-ID: <1526541.obk11Y6NX2@xps13> References: <1489754838-1455-2-git-send-email-hemant.agrawal@nxp.com> <21940728.tivBTtkBCF@xps13> <5f4fe240-8f17-0d4f-04b7-a8dd04b2c16e@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Hemant Agrawal , Olivier MATZ , dev@dpdk.org, shreyansh.jain@nxp.com To: Ferruh Yigit Return-path: Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 699242BB0 for ; Tue, 11 Apr 2017 14:50:16 +0200 (CEST) Received: by mail-wr0-f177.google.com with SMTP id l28so38684628wre.0 for ; Tue, 11 Apr 2017 05:50:16 -0700 (PDT) In-Reply-To: <5f4fe240-8f17-0d4f-04b7-a8dd04b2c16e@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-04-11 09:39, Ferruh Yigit: > On 4/11/2017 8:50 AM, Thomas Monjalon wrote: > > 2017-04-11 11:28, Hemant Agrawal: > >> On 4/11/2017 1:28 AM, Olivier MATZ wrote: > >>> Hemant Agrawal wrote: > >>>> --- a/drivers/bus/Makefile > >>>> +++ b/drivers/bus/Makefile > >>>> @@ -33,6 +33,10 @@ include $(RTE_SDK)/mk/rte.vars.mk > >>>> > >>>> core-libs := librte_eal librte_mbuf librte_mempool librte_ring librte_ether > >>>> > >>>> +ifeq ($(CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL),y) > >>>> +CONFIG_RTE_LIBRTE_FSLMC_BUS = $(CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL) > >>>> +endif > >>>> + > >>>> DIRS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += fslmc > >>>> DEPDIRS-fslmc = ${core-libs} > >>>> > >>> > >>> What's the purpose of this? > >>> Not sure we are allowed to modify the configs in the Makefiles. > >> > >> DPAA2_MEMPOOL will not work without the DPAA2 mempool hw instance > >> detected on FSLMC_BUS. > >> So, it is required that if you are enabling DPAA2_MEMPOOL, FSLMC_BUS is > >> to be enabled. > >> > >> Currently the config structure do not provide such dependency definitions. > >> > >> This was done based on the suggestions on the initial patches from > >> Ferruh and Jerin. > > > > Please do not do that. > > We do not change the configuration in the back of the user. > > This kind of dependency should be managed in the configuration step > > which do not exist yet. > > > > You can use $(error) to stop the compilation instead. > > As Hemant mentioned, this was my suggestion. There is a configuration > dependency here, that we don't have a way to resolve in dpdk. > > If one of the end leaf selected, it makes sense to me to auto select > dependent pieces. A dependency must be solved at configuration time with appropriate user notification. For now, we just check them at compilation time and throw an error.