From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2EE813B5 for ; Thu, 21 Apr 2016 10:57:01 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81E3AC056819; Thu, 21 Apr 2016 08:56:59 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-204.ams2.redhat.com [10.36.5.204]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3L8uwvL023324; Thu, 21 Apr 2016 04:56:58 -0400 To: apanda@cs.berkeley.edu References: <57158D01.5020407@cs.berkeley.edu> <57173EA4.9000208@redhat.com> <5717917D.9030504@cs.berkeley.edu> Cc: users@dpdk.org From: Panu Matilainen Message-ID: <571895D9.3090700@redhat.com> Date: Thu, 21 Apr 2016 11:56:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5717917D.9030504@cs.berkeley.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Subject: Re: [dpdk-users] DPDK 16.04 link changes cause PMD drivers to not be loaded X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:57:01 -0000 On 04/20/2016 05:26 PM, Aurojit Panda wrote: > I am sorry that is a bit unintuitive considering: > > (a) This behavior differs between static and shared builds of DPDK. > - In fact this behavior was identical in 2.2, and even in mainline > before 948fd64befc3726 went in. > (b) You already know the EAL_PMD_PATH at build time, and it makes it > quite hard to ship scripts or anything to build DPDK, since now the > configuration file becomes dependent on location. The expectation is that shared libraries are installed to a shared, known location. Otherwise there's not that much point in using shared libraries. Note that you can also use the EAL option -d to load either single PMDs or entire directories at runtime (regardless of EAL_PMD_PATH) so you dont have to know the path at build time if that's what bothers you most. > > I wonder if you would consider changing this, as it stands just building > DPDK after setting CONFIG_RTE_SHARED_LIB=y results in a testpmd that > cannot run. In shared library configuration, testpmd is not directly runnable regardless of the drivers since its missing all the other libraries too: [pmatilai@sopuli dpdk]$ build/app/testpmd build/app/testpmd: error while loading shared libraries: librte_distributor.so.1.1: cannot open shared object file: No such file or directory [pmatilai@sopuli dpdk]$ You'll need to get those libraries into linkers path anyway, either by installing them to a common location or by extending LD_LIBRARY_PATH. In either case, you need to know where the libraries are anyway. All of which is not to say there might not be room for improvement, but the linking behavior is not going to change. Again, PMDs are *plugins* that are *meant* to be loaded at runtime. That allows for all sorts of flexibility especially for packaging and shipping, at some extra cost in setup complexity. For your own purposes, you can of course tweak the linking settings as much as you like. Look for "plugins" in mk/rte.app.mk and change the shared lib condition on the line above to "y" and there you have it. But that's not the way plugins are meant to be used. Oh and BTW, please don't top-post. - Panu -