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 2936D590E for ; Fri, 30 Sep 2016 12:31:26 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 6A76B4ACC1; Fri, 30 Sep 2016 10:31:25 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-23.ams2.redhat.com [10.36.6.23]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8UAVNrB026147; Fri, 30 Sep 2016 06:31:24 -0400 To: Bruce Richardson , Christian Ehrhardt References: <45bb513b-660d-ba74-44cc-0761c7068df6@redhat.com> <20160930101522.GB67296@bricha3-MOBL3> Cc: Daniele Di Proietto , James Page , dev , Luca Boccassi From: Panu Matilainen Message-ID: Date: Fri, 30 Sep 2016 13:31:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160930101522.GB67296@bricha3-MOBL3> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 30 Sep 2016 10:31:25 +0000 (UTC) Subject: Re: [dpdk-dev] Did we reduce unnecessary linkage too well? 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, 30 Sep 2016 10:31:26 -0000 On 09/30/2016 01:15 PM, Bruce Richardson wrote: > On Thu, Sep 29, 2016 at 09:26:48AM +0200, Christian Ehrhardt wrote: >> On Thu, Sep 29, 2016 at 9:20 AM, Panu Matilainen >> wrote: >> >>> >>> Yup. Set CONFIG_RTE_EAL_PMD_PATH to the path where your PMDs are >>> installed. Note that since the plugin autoloader in DPDK doesn't make >>> assumptions about names, it'll try to load *everything* in that path, so >>> you don't want it pointing to eg /usr/lib directly. > > Is this something we should look to change? To me having some sort of > naming convention might not be a bad thing, so that we can point it at generic > folders. Plugins for program/library X are nearly always in a sub-directory of their own, outside the linker path because ... well, they're plugins and not something you should link to, and having them in separate directories makes it possible to have multiple versions co-exist on the system by simply placing the plugins into a versioned directory. That's why the current plugin autoloader is the way it is - it's the de-facto standard for dealing with plugins. The DPDK case is a bit convoluted since some of the alleged plugins also provide library APIs, so at least those DSOs need to be present in linker paths. Plugins usually also lack soname version, because that doesn't make much sense for plugins, libraries with APIs are different there too. Anyway, naming conventions are flimsy and fall apart in situations that the directory approach easily handles. So I dont see a point in changing that. What *would* be good is creating and populating that directory from DPDK "make install" step automatically, at least when RTE_EAL_PMD_PATH is set. - Panu - > > /Bruce >