From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7932FA10DA for ; Thu, 1 Aug 2019 18:51:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 847251BF10; Thu, 1 Aug 2019 18:51:16 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 3A5791BE9E for ; Thu, 1 Aug 2019 18:51:13 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2019 09:51:12 -0700 X-IronPort-AV: E=Sophos;i="5.64,334,1559545200"; d="scan'208";a="177883876" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.61]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2019 09:51:10 -0700 Date: Thu, 1 Aug 2019 17:51:07 +0100 From: Bruce Richardson To: Aaron Conole Cc: dev@dpdk.org, Michael Santana , David Marchand , Ferruh Yigit , Luca Boccassi Message-ID: <20190801165107.GB1716@bricha3-MOBL.ger.corp.intel.com> References: <20190731145030.19956-1-aconole@redhat.com> <20190731145030.19956-2-aconole@redhat.com> <20190731153608.GG1705@bricha3-MOBL.ger.corp.intel.com> <20190801091935.GA1716@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Aug 01, 2019 at 11:40:33AM -0400, Aaron Conole wrote: > Bruce Richardson writes: > > > On Wed, Jul 31, 2019 at 12:10:55PM -0400, Aaron Conole wrote: > >> Aaron Conole writes: > >> > >> > Bruce Richardson writes: > >> > > >> >> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote: > >> >>> From: Michael Santana > >> >>> > >> >>> Currently many unit tests fail when running tests under shared builds. > >> >>> This happens because of missing driver dependencies. This is fixed by > >> >>> explicitly linking in missing drivers for the test application. > >> >>> > >> >>> before and after (clang): > >> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623 > >> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620 > >> >>> > >> >>> Suggested-by: Bruce Richardson > >> >>> Suggested-by: David Marchand > >> >>> Signed-off-by: Michael Santana > >> >>> Signed-off-by: Aaron Conole > >> >>> --- > >> >> Rather than linking in the libraries explicitly, can you have the build do > >> >> a "ninja install" at the end to place the libraries and drivers in their > >> >> correct paths. That should mean that the test app (via eal) auto-loads all > >> >> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make > >> >> further changes to this file to link in any additional drivers. > >> > >> Oops, forgot to include a link to a build where I did this. It's > >> failing (you can see the corresponding commit at > >> https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d): > >> > >> https://travis-ci.org/orgcandman/dpdk/jobs/566044409 > >> > > I think the error may be due to having some drivers already linked in while > > trying to reload all drivers dynamically. The dynamic loading of drivers I > > actually think we could make more robust. For example: > > > > * only load .so files. If you pass in the drivers path from the build, it > > errors out trying to load .a files > > * when loading directories, maybe skip any files which don't have a "librte" > > prefix - anyone who has their own drivers they want loaded can add the > > prefix or load it explicitly via -d > > * alternatively, skip files which don't have a pmdinfo section in them > > * allow skipping of drivers which are already linked in > > * don't fail the whole process if one driver fails to load from a > > directory. > > What change do you suggest I make to the steps I outlined? I think it > seems to be more complex than a simple 'ninja install'. > > Maybe it makes sense to merge these patches now and fix the library > loading code as a separate action? Or is there a different procedure I > (and other developers) should follow? Does it really need a 'ninja > install' even for a drive-by developer to make a small patch and test > before submitting? > I think your patch is the best solution for 19.08. Fixing the library loading for developers is a larger job beyond that. Another item for future consideration: since meson/ninja automatically sets the rpath for binaries in build directory - and then strips that out on install - it would be really nice if we could leverage that somehow for finding drivers. /Bruce