From: Panu Matilainen <pmatilai@redhat.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in shared, non-combined config
Date: Mon, 16 Feb 2015 13:58:21 +0200 [thread overview]
Message-ID: <54E1DB5D.9000700@redhat.com> (raw)
In-Reply-To: <4097369.UqpyrEhzLH@xps13>
On 02/16/2015 01:17 PM, Thomas Monjalon wrote:
> 2015-02-16 12:01, Panu Matilainen:
>> On 02/13/2015 03:18 PM, Thomas Monjalon wrote:
>>> 2015-02-13 12:33, Panu Matilainen:
>>>> On 02/13/2015 11:28 AM, Thomas Monjalon wrote:
>>>>> 2015-02-13 09:27, Panu Matilainen:
>>>>>> On 02/12/2015 05:44 PM, Thomas Monjalon wrote:
>>>>>>> A library is considered as a plugin if there is no public API and it
>>>>>>> registers itself. That's the case of normal PMD.
>>>>>>> But bonding and Xen have some library parts with public API.
>>>>>>> It has been discussed and agreed for bonding but I'm not aware of the Xen case.
>>>>>>
>>>>>> Fair enough, thanks for the explanation.
>>>>>>
>>>>>> Just wondering about versioning of these things - currently all the PMDs
>>>>>> are versioned as well, which is slightly at odds with their expected
>>>>>> usage, dlopen()'ed items usually are not versioned because it makes the
>>>>>> files moving targets. But if a plugin can be an library too then it
>>>>>> clearly needs to be versioned as well.
>>>>>
>>>>> Not sure to understand your considerations.
>>>>> Plugins must be versioned because there can be some incompatibilities
>>>>> like mbuf rework.
>>>>
>>>> Plugins are version-dependent obviously, but the issue is somewhat
>>>> different from library versioning. Plugins are generally consumers of
>>>> the versioned ABIs, whereas libraries are the providers.
>>>>
>>>>>> I'm just thinking of typical packaging where the unversioned *.so
>>>>>> symlinks are in a -devel subpackage and the versioned libraries are in
>>>>>> the main runtime package. Plugins should be loadable by a stable
>>>>>> unversioned name always, for libraries the linker handles it behind the
>>>>>> scenes. So in packaging these things, plugin *.so links need to be
>>>>>> handled differently (placed into the main package) from others. Not
>>>>>> rocket science to filter by 'pmd' in the name, but a new twist anyway
>>>>>> and easy to get wrong.
>>>>>>
>>>>>> One possibility to make it all more obvious might be having a separate
>>>>>> directory for plugins, the mixed case ccould be handled by symlinks.
>>>>>
>>>>> I think I don't understand which use case you are trying to solve.
>>>>
>>>> Its a usability/documentation issue more than a technical one. If plugin
>>>> DSO's are versioned (like they currently are), then loading them via eg
>>>> -d becomes cumbersome since you need to hunt down and provide the
>>>> versioned name, eg "testpmd -d librte_pmd_pcap.so.1 [...]"
>>>>
>>>> Like said above, it can be worked around by leaving the unversioned
>>>> symlinks in place for plugins in runtime (library) packages, but that
>>>> sort of voids the point of versioning. One possibility would be
>>>> introducing a per-version plugin directory that would be used as the
>>>> default path for dlopen() unless an absolute path is used.
>>>
>>> It makes me think that instead of using a -d option per plugin, why not
>>> adding a -D option to load all plugins from a directory?
>>
>> Are you thinking of "-D <plugindir>" or just -D (to use a build-time
>> hardwired directory)?
>
> I'm thinking of "-D <plugindir>".
> I understand you would like a "hardwired" default directory which would be
> properly packaged by a distribution. Maybe that it could be a build-time
> default to load all the plugins of a directory (without option). Then the
> -d and -D options would overwrite the build-time default behaviour.
Hmm, indeed. What I generally want is software to just DTRT when at all
possible. For plugins, that typically means "load all installed/enabled
plugins automatically unless manually overridden".
This becomes even more of an issue if/when the "combine everything"
libintel_dpdk library in its current form is eliminated (I am fully in
favor of that) since that has practically hidden the plugins from its
users like openvswitch.
- Panu -
- Panu -
next prev parent reply other threads:[~2015-02-16 11:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 8:53 Panu Matilainen
2015-02-11 10:51 ` Gonzalez Monroy, Sergio
2015-02-11 11:25 ` Panu Matilainen
2015-02-11 12:31 ` Gonzalez Monroy, Sergio
2015-02-12 15:44 ` Thomas Monjalon
2015-02-13 7:27 ` Panu Matilainen
2015-02-13 9:28 ` Thomas Monjalon
2015-02-13 10:33 ` Panu Matilainen
2015-02-13 10:53 ` Thomas Monjalon
2015-02-13 13:18 ` Thomas Monjalon
2015-02-16 10:01 ` Panu Matilainen
2015-02-16 11:17 ` Thomas Monjalon
2015-02-16 11:58 ` Panu Matilainen [this message]
2015-02-11 13:43 ` [dpdk-dev] [PATCH v2] mk: fix librte_vhost linking Panu Matilainen
2015-02-11 13:47 ` Gonzalez Monroy, Sergio
2015-02-12 16:00 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E1DB5D.9000700@redhat.com \
--to=pmatilai@redhat.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).