From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCHv6 16/33] drivers/pool/dpaa2: adding hw offloaded mempool Date: Tue, 24 Jan 2017 14:42:03 +0530 Message-ID: <33f05835-47aa-39d3-0338-01ab165be6d9@nxp.com> References: <1484832240-2048-1-git-send-email-hemant.agrawal@nxp.com> <1485172803-17288-1-git-send-email-hemant.agrawal@nxp.com> <1485172803-17288-17-git-send-email-hemant.agrawal@nxp.com> <7c521c9c-e868-81c1-39ec-ae26db8fbf69@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Hemant Agrawal , , , , , To: Ferruh Yigit Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0053.outbound.protection.outlook.com [104.47.38.53]) by dpdk.org (Postfix) with ESMTP id C161E108D for ; Tue, 24 Jan 2017 10:07:28 +0100 (CET) In-Reply-To: <7c521c9c-e868-81c1-39ec-ae26db8fbf69@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" On Monday 23 January 2017 11:04 PM, Ferruh Yigit wrote: > On 1/23/2017 11:59 AM, Hemant Agrawal wrote: >> Adding NXP DPAA2 architecture specific mempool support >> Each mempool instance is represented by a DPBP object >> from the FSL-MC bus. >> >> This patch also registers a dpaa2 type MEMPOOL OPS >> >> Signed-off-by: Hemant Agrawal >> --- > <...> > >> diff --git a/drivers/common/Makefile b/drivers/common/Makefile >> index b52931c..0bb75b5 100644 >> --- a/drivers/common/Makefile >> +++ b/drivers/common/Makefile >> @@ -35,7 +35,11 @@ ifeq ($(CONFIG_RTE_LIBRTE_DPAA2_PMD),y) >> CONFIG_RTE_LIBRTE_DPAA2_COMMON = $(CONFIG_RTE_LIBRTE_DPAA2_PMD) >> endif >> >> -ifeq ($(CONFIG_RTE_LIBRTE_FSLMC_BUS),y) >> +ifeq ($(CONFIG_RTE_LIBRTE_DPAA2_POOL),y) >> +CONFIG_RTE_LIBRTE_DPAA2_COMMON = $(CONFIG_RTE_LIBRTE_DPAA2_POOL) >> +endif >> + >> +ifneq ($(CONFIG_RTE_LIBRTE_FSLMC_BUS),y) > > I guess this is a typo, but this prevents DPAA2_COMMON to be compiled !! It should be 'ifeq' rather than 'ifneq'. And it will prevent COMMON compilation only if CONFIG_RTE_LIBRTE_FSLMC_BUS=n which is not the case right now. We will fix it. > >> CONFIG_RTE_LIBRTE_DPAA2_COMMON = $(CONFIG_RTE_LIBRTE_FSLMC_BUS) >> endif >> > > <...> >> +# library dependencies >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_eal >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_mempool >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_common_dpaa2_qbman > > This dependeny doesn not looks correct, there is no folder like that. This is something even I need to understand. From the DEPDIRS what I understood was that though it refers to a directory, it essentially links libraries in build/lib/*. Further, somehow the development is deploying drivers/bus, drivers/common and drivers/pool in lib/* under the name specified as LIB in Makefile. My understanding was that it is expected behavior and not special because of drivers folder. Thus, above line only links lib/librte_common_dpaa2_qbman generated by drivers/common/dpaa2/qbman code. In fact, I think, this might also one of the issues why a parallel shared build fails for DPAA2 PMD (added in Cover letter). The dependency graph cannot create a graph for drivers/common as dependency for drivers/net or drivers/bus and hence parallel build fails because of missing libraries which are being parallely compiled. > >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_bus_fslmc >> + >> +include $(RTE_SDK)/mk/rte.lib.mk > > <...> >