From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aurojit Panda Subject: Re: [dpdk-users] DPDK 16.04 link changes cause PMD drivers to not be loaded Date: Thu, 21 Apr 2016 08:24:23 -0700 Message-ID: <5718F0A7.7080002@cs.berkeley.edu> References: <57158D01.5020407@cs.berkeley.edu> <571895D9.3090700@redhat.com> <5718EB59.5010808@cs.berkeley.edu> <2358356.HZLcvC2y3R@xps13> Reply-To: apanda@cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Panu Matilainen To: Thomas Monjalon Return-path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 897E03B5 for ; Thu, 21 Apr 2016 17:24:27 +0200 (CEST) Received: by mail-pf0-f181.google.com with SMTP id 184so31397505pff.0 for ; Thu, 21 Apr 2016 08:24:27 -0700 (PDT) In-Reply-To: <2358356.HZLcvC2y3R@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > Thanks Thanks Panda