[dpdk-dev] Did we reduce unnecessary linkage too well?
Panu Matilainen
pmatilai at redhat.com
Fri Sep 30 12:31:23 CEST 2016
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 <pmatilai at redhat.com>
>> 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
>
More information about the dev
mailing list