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 5D02AA10DA for ; Thu, 1 Aug 2019 17:40:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 03EFD1C1D6; Thu, 1 Aug 2019 17:40:38 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0CA521C1BF for ; Thu, 1 Aug 2019 17:40:36 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 654903179B52; Thu, 1 Aug 2019 15:40:35 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B19141001281; Thu, 1 Aug 2019 15:40:34 +0000 (UTC) From: Aaron Conole To: Bruce Richardson Cc: dev@dpdk.org, Michael Santana , David Marchand , Ferruh Yigit , Luca Boccassi 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> Date: Thu, 01 Aug 2019 11:40:33 -0400 In-Reply-To: <20190801091935.GA1716@bricha3-MOBL.ger.corp.intel.com> (Bruce Richardson's message of "Thu, 1 Aug 2019 10:19:36 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 01 Aug 2019 15:40:35 +0000 (UTC) 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" 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? > Regards, > /Bruce