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 498F12BD4 for ; Fri, 22 Apr 2016 12:08:21 +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 8765062654; Fri, 22 Apr 2016 10:08:20 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-182.ams2.redhat.com [10.36.5.182]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3MA8Icm020588; Fri, 22 Apr 2016 06:08:19 -0400 From: Panu Matilainen To: apanda@cs.berkeley.edu, Thomas Monjalon References: <57158D01.5020407@cs.berkeley.edu> <571895D9.3090700@redhat.com> <5718EB59.5010808@cs.berkeley.edu> <2358356.HZLcvC2y3R@xps13> <5718F0A7.7080002@cs.berkeley.edu> Cc: dev@dpdk.org Message-ID: <5719F812.2060903@redhat.com> Date: Fri, 22 Apr 2016 13:08:18 +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: <5718F0A7.7080002@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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 22 Apr 2016 10:08:20 +0000 (UTC) Subject: Re: [dpdk-dev] [dpdk-users] DPDK 16.04 link changes cause PMD drivers to not be loaded X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 10:08:21 -0000 On 04/21/2016 06:24 PM, Aurojit Panda wrote: > > > Thomas Monjalon wrote: >> 2016-04-21 08:01, Aurojit Panda: >>> Panu Matilainen wrote: >> [...] >>>> 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. >>> I am all for a plugin architecture, I was merely suggesting that you >>> embed some path infromation at the beginning. Also please note: >>> (a) This behavior changed recently. >> >> What changed recently? >> > Change 948fd64befc3726 moved DPDK from building a shared library to > using LD linker scripts. > >>> (b) This change is entirely undocumented, which is why I was reporting >>> it in the first place. >>> (c) It is actually quite unintutive, because previously ensuring >>> LD_LIBRARY_PATH was correct was all that was required >>> to get any DPDK application to interact with ports. >> >> ? >> Are you talking about combined library? > Yes, if you build a shared combined library, PMD drivers are not > automatically loaded anymore. This implies that programs do not > enumerate the set of ports on the machine. (Unless CONFIG_EAL_PMD_PATH > is correctly set to the absolute directory where the built DPDK will live). >> >>>> 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. >>> That is not a reasonable solution given that it makes it very hard to >>> track future changes to DPDK without merges. >>> My alternatives neither break people's abilities to use plugins, >>> nor do they impact behavior. >> >> Please do not hesitate to send some patch to show your solution. > > My initial e-mail was sent because I don't entirely understand LD linker > scripts (the PMD libraries are listed within the built libdpdk.so file), > so the only patch I can suggest is undoing 948fd64befc3726 in which case > the behavior as I describe. Reverting would be counter-productive, the change was introduced for a reason. Many of them in fact. Any application wanting to force linkage to plugins always needed to link them inside --whole-archive section with static or individual shared libraries, now that is true for the combined shared library as well. Within DPDK itself it would be easy enough to add an option to force link-in of the plugins (see the comment about mk/rte.app.mk change), but not sure we want to have yet another build option. And anything else still would need to use --whole-archive if they want that behavior. So yes it's a behavior change for that particular corner which nobody thought of or brought up during review, and so ended up being undocumented too. Like said there are always ways to improve things, once the use-case is understood, actual examples of how you are deploying DPDK would perhaps help. One possibility could be attempting to load known plugins from LD_LIBRARY_PATH, but that requires inserting that information somewhere in the binaries where it currently is not needed. - Panu -