[dpdk-dev] DPDK namespace

Wiles, Keith keith.wiles at intel.com
Wed Apr 6 16:36:03 CEST 2016


>On 04/06/2016 08:26 AM, Yuanhan Liu wrote:
>> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
>>> On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona <fiona.trahe at intel.com> wrote:
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>>>>> Sent: Tuesday, April 05, 2016 2:57 PM
>>>>> To: dev at dpdk.org
>>>>> Subject: [dpdk-dev] DPDK namespace
>>>>>
>>>>> DPDK is going to be more popular in Linux distributions.
>>>>> It means people will have some DPDK files in their /usr/include and some
>>>> DPDK
>>>>> libraries on their system.
>>>>>
>>>>> Let's imagine someone trying to compile an application which needs
>>>>> rte_ethdev.h. He has to figure out that this "rte header" is provided by
>>>> the DPDK.
>>>>> Hopefully it will be explained on StackOverflow that RTE stands for DPDK.
>>>>> Then someone else will try to run a binary without having installed the
>>>> DPDK
>>>>> libraries. The linker will require libethdev.so (no prefix here).
>>>>> StackOverflow will probably have another good answer (among wrong ones):
>>>>> "Hey Sherlock Holmes, have you tried to install the DPDK library?"
>>>>> Followed by an insight: "You know, the DPDK naming is weird..."
>>>>> And we could continue the story with developers having some naming clash
>>>>> because of some identifiers not prefixed at all.
>>>>>
>>>>> The goal of this email is to get some feedback on how important it is to
>>>> fix the
>>>>> DPDK namespace.
>>>>>
>>>>> If there is enough agreement that we should do something, I suggest to
>>>>> introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_"
>>>>> during some time.
>>>>> We could start using the new prefix for the new APIs (example: crypto)
>>>> or when
>>>>> there is a significant API break (example: mempool).
>>>>>
>>>>> Opinions welcome!
>>>> I don't have an opinion on how important it is to fix the namespace,
>>>> though it does seem like a good idea.
>>>> However if it's to be done, in my opinion it should be completed quickly
>>>> or will just cause more confusion.
>>>> So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should
>>>> follow in next release or two, with
>>>> the resulting ABI compatibility handling. Maybe with dual naming handled
>>>> for several releases, but a
>>>> clear end date when all are converted.
>>>> Else there will be many years with a mix of rte_ and dpdk_
>>>>
>>>>
>>>
>>> Googling rte functions or error codes usually takes you to dpdk dev email
>>> archive so I don't think it is that much difficult to figure out where rte
>>> comes from.
>>> Other than that , except for my own refactoring pains when replacing a dpdk
>>> version, I do not see a major reason why not.
>>> If Going for dpdk_ prefix, I agree with the quick death approach.
>>
>> +1: it's a bit weird to keep both, especially for a long while, that
>> every time we turn a rte_ prefix to dpdk_ prefix, we break applications.
>> Instead of breaking applications many times, I'd prefer to break once.
>> Therefore, applications could do a simple global rte_ -> dpdk_ substitute:
>> it doesn't sound that painful then.
>
>I concur. If (and I think that should be a pretty big IF) the prefix is 
>to be changed then its better done in one fast sweep than gradually.
>
>Gratuitious (or nearly so) change is always extremely annoying, and the 
>longer it takes the more painful it is. Application developers wont much 
>care what the prefix is as long as its consistent, but if they're forced 
>to track prefix changes across several releases with different libraries 
>moving at different pace, they WILL be calling for bloody murder :)
>
>As for rte_ being strange for DPDK - yes it is, but it takes like 5 
>minutes to get over it. It would help to have it explained on dpdk.org 
>FAQ: "Due to historical reasons, DPDK libraries are prefixed rte_ 
>instead of dpdk_ because <insert excuse here, probably early project 
>name> and changing it is unnecessarily painful."

As I understand RTE is from the “Run Time Environment” which was the primary set of API’s at the time and it just kept getting propagated :-)

>
>>
>> And here are few more comments:
>>
>> - we should add rte_/dpdk_ prefix to all public structures as well.
>>
>>    I'm thinking we are doing well here. I'm just aware that vhost lib
>>    does a bad job, which is something I proposed to fix in next release.
>
>Yup, all public symbols should be prefixed. What the exact prefix is 
>isn't that important really.
>
>>
>> - If we do the whole change once, I'd suggest to do it ASAP when this
>>    release is over.
>>
>>    It should be a HUGE change that touches a lot of code, if we do it
>>    later, at a stage that a lot of patches for new features have been
>>    made or sent out, all of them need rebase. That'd be painful.
>
>Nod, that's yet another aspect to consider.
>
>So to summarize, I'm not strongly opposed to doing a one-time mass rte_ 
>-> dpdk_ prefix change, but it needs to be one big sweep all at once, or 
>not do it at all. Gradual change is a suicide.
>
>Keeping rte_ is not the end of the world by any means, especially when 
>applied consistently and explained someplace.

To me rte_ is just fine, plus we have to change the structures names and defines names. I am sure we can figure out a script to convert any app for the developer, but why change. The rte_ prefix is something which can be explained and dpdk_ adds one character to type :-)

>
>	- Panu -
>


Regards,
Keith






More information about the dev mailing list