From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0083.outbound.protection.outlook.com [104.47.0.83]) by dpdk.org (Postfix) with ESMTP id 69ED51023 for ; Wed, 25 Jan 2017 14:35:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pw7fnEX06hdGiu7ypZSZe/hHwMbjOGWJaiiVJRjYLU4=; b=xwIc/rriiK2TdwRddRmO//tdw0DiwcvcNgyP+XgdiNfiTDa6hlMEuiYpggvKbQKrCNQesErrLkYEh2e0rQjJOGUiCG6yd9Uj7jswKt9rSR5JoI4UtDqZVFdxKogB/I1BOX3sGGVd63mqweBYbUz/e2vfbpBrEW985BGvV614lzE= Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com (10.166.11.137) by AM4PR04MB1602.eurprd04.prod.outlook.com (10.164.78.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 25 Jan 2017 13:35:10 +0000 Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) by DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) with mapi id 15.01.0860.021; Wed, 25 Jan 2017 13:35:10 +0000 From: Shreyansh Jain To: Neil Horman , Thomas Monjalon CC: Hemant Agrawal , Ferruh Yigit , "dev@dpdk.org" , "bruce.richardson@intel.com" , "john.mcnamara@intel.com" , "jerin.jacob@caviumnetworks.com" Thread-Topic: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw offloaded mempool Thread-Index: AQHSdXBkONloxmme/UKrk8xEErALDaFGUvMAgAEhNIiAAD+ggIAAMAmAgAE89ACAABKSYA== Date: Wed, 25 Jan 2017 13:34:47 +0000 Deferred-Delivery: Wed, 25 Jan 2017 13:34:36 +0000 Message-ID: References: <1484832240-2048-1-git-send-email-hemant.agrawal@nxp.com> <228ff5e7-2fa8-7731-681d-e4759bff93cb@nxp.com> <20101825.1zhD9dk20U@xps13> <20170125122324.GA4611@hmswarspite.think-freely.org> In-Reply-To: <20170125122324.GA4611@hmswarspite.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; x-originating-ip: [192.88.169.1] x-microsoft-exchange-diagnostics: 1; AM4PR04MB1602; 7:Is/wxB8xOpJlI4gYDdwplg15tqEURgh2a25r3XoOur6MJumcM6Jd+z51pSKkzAsz9IvatqmjwH1AWsSfGwsfrlfyJ/ugqiQ+7rg1kLfY3SLVP7MmaWcdNjsA0MlYUAz1Y0aK+ApRUJJJ88MzDMKcB9IBstvuAz8i73gB4pTpEoWlUBvotKmj2b86XHI/pYtxIBvof+ptXZ/bzlaV/opxxNI4/tv8XGAIvNzMq+OZcXDj4Sv97AHHjGl0rwCwkAWwOeQzW8526yKmUi4au1exbXnXF9LRU5O8uR7fa0InwskEJwIIqPG3m2zW08s3k6mQ/++UJrAwzTAhYEzU2AwOrVwtJ3nvHtPaJX8+jATt6OfhwozeXQGcQhR1CHAoQUHZnJZWfZokZqP69uQSUMrI512OJr2iDWRgbgLgYPy6FmxLPaWc5afMnxDPNodYNRzKQ0/N5+5byyKU1Qx5MgJP3A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39860400002)(39850400002)(39450400003)(39840400002)(189002)(377454003)(24454002)(377424004)(13464003)(199003)(81166006)(9686003)(3660700001)(305945005)(106116001)(81156014)(33656002)(8676002)(76176999)(101416001)(93886004)(8936002)(105586002)(68736007)(6666003)(106356001)(2950100002)(7696004)(74316002)(66066001)(7736002)(54356999)(4326007)(86362001)(2906002)(53936002)(3280700002)(122556002)(50986999)(5660300001)(102836003)(6116002)(5001770100001)(6506006)(3846002)(92566002)(54906002)(99286003)(97736004)(55016002)(77096006)(38730400001)(25786008)(229853002)(6436002)(2900100001)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR04MB1602; H:DB5PR0401MB2054.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 836df608-1a0d-450f-d210-08d44526fbcd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR04MB1602; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(20161123560025)(6047074)(6072148); SRVR:AM4PR04MB1602; BCL:0; PCL:0; RULEID:; SRVR:AM4PR04MB1602; x-forefront-prvs: 01986AE76B received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2017 13:35:09.9764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR04MB1602 Subject: Re: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw offloaded mempool X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 13:35:12 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, January 25, 2017 5:53 PM > To: Thomas Monjalon > Cc: Hemant Agrawal ; Ferruh Yigit > ; Shreyansh Jain ; > dev@dpdk.org; bruce.richardson@intel.com; john.mcnamara@intel.com; > jerin.jacob@caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw > offloaded mempool >=20 > On Tue, Jan 24, 2017 at 06:28:59PM +0100, Thomas Monjalon wrote: > > 2017-01-24 20:07, Hemant Agrawal: > > > On 1/24/2017 4:19 PM, Ferruh Yigit wrote: > > > > On 1/24/2017 9:12 AM, Shreyansh Jain wrote: > > > >> On Monday 23 January 2017 11:04 PM, Ferruh Yigit wrote: > > > >>> On 1/23/2017 11:59 AM, Hemant Agrawal wrote: > > > >>>> +# library dependencies > > > >>>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) +=3D lib/librte_eal > > > >>>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) +=3D lib/librte_mempool > > > >>>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) +=3D > lib/librte_common_dpaa2_qbman > > > >>> > > > >>> This dependeny doesn not looks correct, there is no folder like t= hat. > > > >> > > > >> This is something even I need to understand. From the DEPDIRS what= I > > > >> understood was that though it refers to a directory, it essentiall= y > > > >> 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 generate= d 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 bu= ild > > > >> fails because of missing libraries which are being parallely compi= led. > > > > > > > > DEPDIRS-y is mainly to resolve dependencies for compilation order, = and > > > > should point to the folder, > > > > > > > > Following line will cause "librte_eal" to be compiled before driver= : > > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) +=3D lib/librte_eal > > > > > > > > So "lib/librte_common_dpaa2_qbman" does not makes more sense, since > > > > there is no folder like that. > > > > > > > > > > > > Somewhere in the history, with following commit, DEPDIRS-y gained a > side > > > > effect, it has been used to set dynamic linking dependencies, to fi= x > > > > underlinking issue: > > > > bf5a46fa5972 ("mk: generate internal library dependencies") > > > > > > > > I guess you are having that line to benefit from this side effect, = but > > > > this can be done with following more properly: > > > > LDLIBS +=3D lib/librte_common_dpaa2_qbman > > > > > > > > > > > > To resolve the drivers/net to drivers/common dependency, following = line > > > > in this Makefile should work: > > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) +=3D drivers/common/dpaa2 > > > > > > > > This adds following, which will cause "drivers/common" compiled bef= ore > > > > any "drivers/net": > > > > LOCAL_DEPDIRS-drivers/net +=3D drivers/common > > > > > > Thanks for your suggestion. This is one thing, I am not yet able to f= ix. > > > > > > Based on your suggestions: > > > e.g. > > > LDLIBS +=3D -lrte_common_dpaa2_qbman > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) +=3D drivers/common/dpaa2 > > > > > > It does add entry in the ".depdirs" > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:168:LOCAL_DEPDIRS-drivers/bus += =3D > > > drivers/common > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:170:LOCAL_DEPDIRS-drivers +=3D li= b > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:172:LOCAL_DEPDIRS-drivers +=3D li= b > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:174:LOCAL_DEPDIRS-drivers/pool += =3D > > > drivers/common > > > > > > However, we keep on getting: > > > LD librte_bus_fslmc.so.1.1 > > > aarch64-linux-gnu-gcc: error: drivers/common/dpaa2: No such file or > > > directory > > > make[6]: *** [librte_bus_fslmc.so.1.1] Error 1 > > > > Probably because of: > > > > # Translate DEPDIRS-y into LDLIBS > > # Ignore (sub)directory dependencies which do not provide an actual lib= rary > > _IGNORE_DIRS =3D lib/librte_eal/% lib/librte_compat > > _DEPDIRS =3D $(filter-out $(_IGNORE_DIRS),$(DEPDIRS-y)) > > _LDDIRS =3D $(subst librte_ether,librte_ethdev,$(_DEPDIRS)) > > LDLIBS +=3D $(subst lib/lib,-l,$(_LDDIRS)) > > > > It shows one important thing: qbman is not a driver, it is a lib. > > So drivers/common/dpaa2 should be handled differently. > > > > Solution 1: tweak mk/rte.lib.mk for directories in drivers/common/ > > Solution 2: host your bus libs outside of DPDK > Please do not go with suggestion two, the more libraries get hosted outsi= de > of > the project, the less likely any sort of test/build/ongoing maintenence f= rom > the > community can be expected. If you're going to go with solution (2), then= you > may as well host the entire PMD outside of the DPDK project, and thats mo= re > undesireable. =20 Agree with you. Hosting a part of PMD (or PMD itself) outside of DPDK is no= t a preferred way for me as well. Besides being non-user-friendly, this has obvious disadvantage of a fragmented software which will quickly become difficult to manage/maintain. But, renaming so many variables also is not an easy choice (assuming that the suggestion from you for MAP_STATIC_SYMBOL is not in place - still investigating on that). Merging everything together has already been ruled out in initial RFC Discussions. >=20 > Neil >=20 > >