[dpdk-dev] DPDK namespace

[dpdk-dev] DPDK namespace

[Thomas Monjalon]

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!

Re: [dpdk-dev] DPDK namespace

[Trahe, Fiona]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, April 05, 2016 2:57 PM
> To: dev@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_ 

Re: [dpdk-dev] DPDK namespace

[Trahe, Fiona]

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Tuesday, April 05, 2016 3:13 PM
> To: Thomas Monjalon; dev@dpdk.org
> Cc: Trahe, Fiona
> Subject: RE: [dpdk-dev] DPDK namespace
> 
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, April 05, 2016 2:57 PM
> > To: dev@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_

An alternative: Would it not be better to do this as one specific 
namespace-change-only release, e.g. an extra 16.06 release, rather than bundling with functional changes?

Re: [dpdk-dev] DPDK namespace

[Arnon Warshavsky]

On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona <fiona.trahe@intel.com> wrote:

>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, April 05, 2016 2:57 PM
> > To: dev@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.

/Arnon

Re: [dpdk-dev] DPDK namespace

[Yuanhan Liu]

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@intel.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > Sent: Tuesday, April 05, 2016 2:57 PM
> > > To: dev@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.

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.

- 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.

	--yliu

Re: [dpdk-dev] DPDK namespace

[Panu Matilainen]

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@intel.com> wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
>>>> Sent: Tuesday, April 05, 2016 2:57 PM
>>>> To: dev@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."

>
> 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.

	- Panu -

Re: [dpdk-dev] DPDK namespace

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, April 06, 2016 1:08 PM
> To: Yuanhan Liu; Arnon Warshavsky
> Cc: Trahe, Fiona; Thomas Monjalon; dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK namespace
> 
> 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@intel.com> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> >>>> Sent: Tuesday, April 05, 2016 2:57 PM
> >>>> To: dev@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."
> 
> >
> > 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.
> 

Yep, I have exactly the same thoughts:
1. Yes, dpdk_'  prefix is a better naming approach than 'rte_',
but for me not that better to overweight all the pain of such big change.
2. If we still decide to do that change - my preference would be to do it in one go. 
I personally don't care that much what the prefix would be, as long as it is consistent
across the whole codebase. 
Konstantin

Re: [dpdk-dev] DPDK namespace

[Jay Rolette]

On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
wrote:

> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
> > 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.
>
> 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.
>
> - 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.
>

This last point that yliu brings up is the one that worries me. DPDK
already has a serious problem with the patch backlog. It can take months
for even small bug fixes to get merged.

>From the app side, it's not the end of the world if there is a one time,
single shot change to the prefix. However, I'm not sure it's worth it
because of the impact on patches that have been submitted. As others have
mentioned, google can sort the rte_* references just fine.

Jay

Re: [dpdk-dev] DPDK namespace

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
> Sent: Wednesday, April 6, 2016 1:41 PM
> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> Cc: Arnon Warshavsky <arnon@qwilt.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Thomas Monjalon <thomas.monjalon@6wind.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK namespace
> 
> On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
> wrote:
> 
> This last point that yliu brings up is the one that worries me. DPDK
> already has a serious problem with the patch backlog. It can take months
> for even small bug fixes to get merged.
> 
> From the app side, it's not the end of the world if there is a one time,
> single shot change to the prefix. However, I'm not sure it's worth it
> because of the impact on patches that have been submitted. As others have
> mentioned, google can sort the rte_* references just fine.

Hi,

Agreed on patches. And if we wanted to do a Long Term Support branch/release based on DPDK 2.2.0 or 16.04 then backporting fixes would be a pain.

John.
-- 

Re: [dpdk-dev] DPDK namespace

[Wiles, Keith]

>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@intel.com> wrote:
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
>>>>> Sent: Tuesday, April 05, 2016 2:57 PM
>>>>> To: dev@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

Re: [dpdk-dev] DPDK namespace

[Dave Neary]

Hi,

On 04/06/2016 08:07 AM, Panu Matilainen wrote:
>> +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 :)

How about the idea of creating (at switch over time) an optionally
installable dpdk_compat package that just has a list of #defines for the
old symbols pointing them at the new symbols? That would also allow
people with old applications to update DPDK without having to modify
their applications.

Thanks,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

Re: [dpdk-dev] DPDK namespace

[Marc]

On 6 April 2016 at 22:21, Dave Neary <dneary@redhat.com> wrote:

> Hi,
>
> On 04/06/2016 08:07 AM, Panu Matilainen wrote:
> >> +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.
>

+1

Either all types and symbols use dpdk_ or rte_. It probably makes more
sense dpdk_, but to me it is not that important.

If it has to be changed, it might be a good idea to do it in this release,
now that version numbering format also changes.

>
> > 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 :)
>
> How about the idea of creating (at switch over time) an optionally
> installable dpdk_compat package that just has a list of #defines for the
> old symbols pointing them at the new symbols? That would also allow
> people with old applications to update DPDK without having to modify
> their applications.
>

You would also have to add all typedefs for type names.

Why bothering? Moving from 2.2 to 16.04 requires recompiling your
application (ABI changes), and is as simple as sed -e 's/rte_/dpdk_/g' in
all the application code base.

Marc


>
> Thanks,
> Dave.
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>

Re: [dpdk-dev] DPDK namespace

[Thomas Monjalon]

Thank you everyone for the feedbacks.

2016-04-05 15:56, Thomas Monjalon:
> The goal of this email is to get some feedback on how important it is
> to fix the DPDK namespace.

Everybody agree every symbols must be prefixed. Checking and fixing the
namespace consistency will be in the roadmap.

It seems most of you agree renaming would be a nice improvement but not
so important.
The main drawback is the induced backporting pain, even if we have
some scripts to convert the patches to the old namespace.
Note: the backports can be in DPDK itself or in the applications.

> 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).

The slow change has been clearly rejected in favor of a complete change
in one patch.
The timing was also discussed as it could impact the pending patches.
So it would be done at the end or the beginning of a release.
Marc suggests to do it for 16.04 as the numbering scheme has changed.

There is no strong conclusion at this point because we need to decide
wether the renaming deserves to be done or never.
I suggest to take the inputs from the technical board.

Do not hesitate to comment. Thanks

Re: [dpdk-dev] DPDK namespace

[Panu Matilainen]

On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
> Thank you everyone for the feedbacks.
>
> 2016-04-05 15:56, Thomas Monjalon:
>> The goal of this email is to get some feedback on how important it is
>> to fix the DPDK namespace.
>
> Everybody agree every symbols must be prefixed. Checking and fixing the
> namespace consistency will be in the roadmap.
>
> It seems most of you agree renaming would be a nice improvement but not
> so important.
> The main drawback is the induced backporting pain, even if we have
> some scripts to convert the patches to the old namespace.
> Note: the backports can be in DPDK itself or in the applications.
>
>> 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).
>
> The slow change has been clearly rejected in favor of a complete change
> in one patch.
> The timing was also discussed as it could impact the pending patches.
> So it would be done at the end or the beginning of a release.
> Marc suggests to do it for 16.04 as the numbering scheme has changed.

Just noting that it cannot be done in 16.04 because the ABI policy 
requires a deprecation cycle of at least one major release for every 
breakage. And we're discussing a total 100% breakage of everything here, 
even if its just a simple rename.

	- Panu -

> There is no strong conclusion at this point because we need to decide
> wether the renaming deserves to be done or never.
> I suggest to take the inputs from the technical board.
>
> Do not hesitate to comment. Thanks
>

Re: [dpdk-dev] DPDK namespace

[Marc Sune]

2016-04-07 11:33 GMT+02:00 Panu Matilainen <pmatilai@redhat.com>:

> On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>
>> Thank you everyone for the feedbacks.
>>
>> 2016-04-05 15:56, Thomas Monjalon:
>>
>>> The goal of this email is to get some feedback on how important it is
>>> to fix the DPDK namespace.
>>>
>>
>> Everybody agree every symbols must be prefixed. Checking and fixing the
>> namespace consistency will be in the roadmap.
>>
>> It seems most of you agree renaming would be a nice improvement but not
>> so important.
>> The main drawback is the induced backporting pain, even if we have
>> some scripts to convert the patches to the old namespace.
>> Note: the backports can be in DPDK itself or in the applications.
>>
>> 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).
>>>
>>
>> The slow change has been clearly rejected in favor of a complete change
>> in one patch.
>> The timing was also discussed as it could impact the pending patches.
>> So it would be done at the end or the beginning of a release.
>> Marc suggests to do it for 16.04 as the numbering scheme has changed.
>>
>
> Just noting that it cannot be done in 16.04 because the ABI policy
> requires a deprecation cycle of at least one major release for every
> breakage. And we're discussing a total 100% breakage of everything here,
> even if its just a simple rename.


I keep not understanding the ABI policy, and particularly why ABI changes
have to be announced once cycle before _if_ there is already at least one
ABI change proposed. DPDK applications will have to recompile anyway.

This aspect of the policy only slows down DPDK development and it pollutes
the repository with commits announcing ABI changes that are irrelevant
after 2 cycles, as (code) diffs show that already (not mentioning NEXT_ABI
complexity and extra LOCs).

Maintaining LTS releases, and enforcing bug fixing in old LTS first,
upstreaming bugfixes is to me a much better approach to solve backwards
compatibility issues.

But this is probably another discussion.

Marc


>
>         - Panu -
>
>
> There is no strong conclusion at this point because we need to decide
>> wether the renaming deserves to be done or never.
>> I suggest to take the inputs from the technical board.
>>
>> Do not hesitate to comment. Thanks
>>
>>
>

[dpdk-dev] On DPDK ABI policy

[Panu Matilainen]

[ change of subject since this is about ABI policy, not namespacing ]

On 04/07/2016 01:16 PM, Marc Sune wrote:
>
>
> 2016-04-07 11:33 GMT+02:00 Panu Matilainen <pmatilai@redhat.com
> <mailto:pmatilai@redhat.com>>:
>
>     On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>
>         Thank you everyone for the feedbacks.
>
>         2016-04-05 15:56, Thomas Monjalon:
>
>             The goal of this email is to get some feedback on how
>             important it is
>             to fix the DPDK namespace.
>
>
>         Everybody agree every symbols must be prefixed. Checking and
>         fixing the
>         namespace consistency will be in the roadmap.
>
>         It seems most of you agree renaming would be a nice improvement
>         but not
>         so important.
>         The main drawback is the induced backporting pain, even if we have
>         some scripts to convert the patches to the old namespace.
>         Note: the backports can be in DPDK itself or in the applications.
>
>             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).
>
>
>         The slow change has been clearly rejected in favor of a complete
>         change
>         in one patch.
>         The timing was also discussed as it could impact the pending
>         patches.
>         So it would be done at the end or the beginning of a release.
>         Marc suggests to do it for 16.04 as the numbering scheme has
>         changed.
>
>
>     Just noting that it cannot be done in 16.04 because the ABI policy
>     requires a deprecation cycle of at least one major release for every
>     breakage. And we're discussing a total 100% breakage of everything
>     here, even if its just a simple rename.
>
>
> I keep not understanding the ABI policy, and particularly why ABI
> changes have to be announced once cycle before _if_ there is already at
> least one ABI change proposed. DPDK applications will have to recompile
> anyway.

The point is to allow API/ABI consumers to assess in advance what sort 
of pains can they expect when moving their applications from one version 
to another. Otherwise all sorts of massive changes could ride the wave 
of whatever "change 16bit struct member to 32bit" trivialities that are 
nevertheless ABI breaks.

There have already been quite a few exceptions to the rule when the ABI 
is already being broken, so its not entirely rigid. Another point that 
migth warrant some tweaking to the policy is the "core" libraries 
depending on each other so an ABI break in any one of them forces 
recompile of everything anyway.

> This aspect of the policy only slows down DPDK development and it

One could also think that slowing down development and forcing people to 
think ahead are not entirely unintentional or unwanted side-effects :)

Look at the latest librte_vhost initiative to remove unnecessarily 
exposed structs to avoid having to deal with ABI breakages all the time: 
the policy is effectively encouraging people into better library design.

> pollutes the repository with commits announcing ABI changes that are
> irrelevant after 2 cycles, as (code) diffs show that already (not
> mentioning NEXT_ABI complexity and extra LOCs).

Fully agreed on NEXT_ABI, I never liked it at all.

> Maintaining LTS releases, and enforcing bug fixing in old LTS first,
> upstreaming bugfixes is to me a much better approach to solve backwards
> compatibility issues.

LTS releases could help the situation somewhat, but then again people 
tend to still want those new fancy things backported (you know, have the 
cake and eat it too) but that can't be done because of ABI breakage, so 
they're forced to run the latest version anyway.

> But this is probably another discussion.

Yup, changed subject to avoid mixing it up with the namespace discussion 
too much.

	- Panu -

Re: [dpdk-dev] DPDK namespace

[Matthew Hall]

On Thu, Apr 07, 2016 at 12:16:34PM +0200, Marc Sune wrote:
> I keep not understanding the ABI policy, and particularly why ABI changes
> have to be announced once cycle before _if_ there is already at least one
> ABI change proposed. DPDK applications will have to recompile anyway.
> 
> This aspect of the policy only slows down DPDK development and it pollutes
> the repository with commits announcing ABI changes that are irrelevant
> after 2 cycles, as (code) diffs show that already (not mentioning NEXT_ABI
> complexity and extra LOCs).
> 
> Maintaining LTS releases, and enforcing bug fixing in old LTS first,
> upstreaming bugfixes is to me a much better approach to solve backwards
> compatibility issues.
> 
> But this is probably another discussion.

Yes, separate discussion. But I agree 100,000%. As a community member in my 
spare time I get tripped up by NEXT_ABI pollution just trying to submit 
trivial patches all the time, then I don't really have any good idea how to 
fix it, and I have to annoy Thomas with dumb questions across the time zones.

I would really prefer to dump all the drama about ABIs and make a maintenance 
only LTS release which only gets bug fixes people specifically need and not 
random fixes or features.

Matthew.

Re: [dpdk-dev] On DPDK ABI policy

[Matthew Hall]

On Thu, Apr 07, 2016 at 02:51:35PM +0300, Panu Matilainen wrote:
> LTS releases could help the situation somewhat, but then again
> people tend to still want those new fancy things backported (you
> know, have the cake and eat it too) but that can't be done because
> of ABI breakage, so they're forced to run the latest version anyway.

RH and Debian / Ubuntu don't put features in LTS except extremely rarely. 
Generally only if there's severe functionality breakage or security issues and 
the rest is ignored, and for good reason, as this is much more reliable and 
simple and predictable.

If people are so irrational they can't deal with that simple of a policy, 
NEXT_ABI, LTS, etc. is never going to help them.

If people like to have backported stuff, yes of course we can make trees and 
branches for this, they are basically free in Git. But at that point community 
people in need of LTS forks of features need to step up to the plate to help 
out.

Matthew.

Re: [dpdk-dev] DPDK namespace

[Thomas Monjalon]

2016-04-07 11:18, Thomas Monjalon:
> 2016-04-05 15:56, Thomas Monjalon:
> > The goal of this email is to get some feedback on how important it is
> > to fix the DPDK namespace.
> 
> Everybody agree every symbols must be prefixed. Checking and fixing the
> namespace consistency will be in the roadmap.
> 
> It seems most of you agree renaming would be a nice improvement but not
> so important.

The main benefits are:
- consistency with the name of the project
- avoid a namespace clash with another library using "rte" prefix
(the dpdk word is kind of reserved now)

> The main drawback is the induced backporting pain, even if we have
> some scripts to convert the patches to the old namespace.
> Note: the backports can be in DPDK itself or in the applications.
> 
> > 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).
> 
> The slow change has been clearly rejected in favor of a complete change
> in one patch.
> The timing was also discussed as it could impact the pending patches.
> So it would be done at the end or the beginning of a release.
> Marc suggests to do it for 16.04 as the numbering scheme has changed.
> 
> There is no strong conclusion at this point because we need to decide
> wether the renaming deserves to be done or never.
> I suggest to take the inputs from the technical board.

The technical board has agreed that the renaming cannot happen in 16.04.
The pro/cons balance need to be discussed more.
The plan is to keep the discussion open during the next 2 weeks and
take a decision based on the discussion outcome.

Re: [dpdk-dev] On DPDK ABI policy

[Marc Sune]

2016-04-07 23:52 GMT+02:00 Matthew Hall <mhall@mhcomputing.net>:

> On Thu, Apr 07, 2016 at 02:51:35PM +0300, Panu Matilainen wrote:
> > LTS releases could help the situation somewhat, but then again
> > people tend to still want those new fancy things backported (you
> > know, have the cake and eat it too) but that can't be done because
> > of ABI breakage, so they're forced to run the latest version anyway.
>
> RH and Debian / Ubuntu don't put features in LTS except extremely rarely.
> Generally only if there's severe functionality breakage or security issues
> and
> the rest is ignored, and for good reason, as this is much more reliable and
> simple and predictable.
>
> If people are so irrational they can't deal with that simple of a policy,
> NEXT_ABI, LTS, etc. is never going to help them.
>
> If people like to have backported stuff, yes of course we can make trees
> and
> branches for this, they are basically free in Git. But at that point
> community
> people in need of LTS forks of features need to step up to the plate to
> help
> out.
>

Completely agree.

Marc


>
> Matthew.
>

Re: [dpdk-dev] On DPDK ABI policy

[Marc Sune]

2016-04-07 13:51 GMT+02:00 Panu Matilainen <pmatilai@redhat.com>:

> [ change of subject since this is about ABI policy, not namespacing ]
>
> On 04/07/2016 01:16 PM, Marc Sune wrote:
>
>>
>>
>> 2016-04-07 11:33 GMT+02:00 Panu Matilainen <pmatilai@redhat.com
>> <mailto:pmatilai@redhat.com>>:
>>
>>     On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>>
>>         Thank you everyone for the feedbacks.
>>
>>         2016-04-05 15:56, Thomas Monjalon:
>>
>>             The goal of this email is to get some feedback on how
>>             important it is
>>             to fix the DPDK namespace.
>>
>>
>>         Everybody agree every symbols must be prefixed. Checking and
>>         fixing the
>>         namespace consistency will be in the roadmap.
>>
>>         It seems most of you agree renaming would be a nice improvement
>>         but not
>>         so important.
>>         The main drawback is the induced backporting pain, even if we have
>>         some scripts to convert the patches to the old namespace.
>>         Note: the backports can be in DPDK itself or in the applications.
>>
>>             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).
>>
>>
>>         The slow change has been clearly rejected in favor of a complete
>>         change
>>         in one patch.
>>         The timing was also discussed as it could impact the pending
>>         patches.
>>         So it would be done at the end or the beginning of a release.
>>         Marc suggests to do it for 16.04 as the numbering scheme has
>>         changed.
>>
>>
>>     Just noting that it cannot be done in 16.04 because the ABI policy
>>     requires a deprecation cycle of at least one major release for every
>>     breakage. And we're discussing a total 100% breakage of everything
>>     here, even if its just a simple rename.
>>
>>
>> I keep not understanding the ABI policy, and particularly why ABI
>> changes have to be announced once cycle before _if_ there is already at
>> least one ABI change proposed. DPDK applications will have to recompile
>> anyway.
>>
>
> The point is to allow API/ABI consumers to assess in advance what sort of
> pains can they expect when moving their applications from one version to
> another. Otherwise all sorts of massive changes could ride the wave of
> whatever "change 16bit struct member to 32bit" trivialities that are
> nevertheless ABI breaks.
>
> There have already been quite a few exceptions to the rule when the ABI is
> already being broken, so its not entirely rigid. Another point that migth
> warrant some tweaking to the policy is the "core" libraries depending on
> each other so an ABI break in any one of them forces recompile of
> everything anyway.
>

In addition to what Matthew said:

I don't understand which sort of pains an announcement saying "we are going
to change this structure and this other, for those high level reasons, but
we don't know exactly how yet, because it is not fully implemented" can be
of any help to a DPDK user. At least it does not to me. This information
has to be in the release notes and users can read that before deciding to
upgrade to a new release.

On the other side, bug fixes still go to NEXT_VERSION. So in 1 ouf ot 2
cases (so far), next release is breaking ABI, so you will have to anyway
recompile your application.

And about ABI breakages; DPDK is not a standard library/library set. For
performance reasons it has a lot of inline code and other optimizations, so
even for small bug fixings can brake ABI, or to be precise, some bug fixes
in inline functions may be silently ignored. I don't know how many users
really use dynamic libraries for DPDK and if there is some warning
somewhere in the documentation for that.


> This aspect of the policy only slows down DPDK development and it
>>
>
> One could also think that slowing down development and forcing people to
> think ahead are not entirely unintentional or unwanted side-effects :)
>
> Look at the latest librte_vhost initiative to remove unnecessarily exposed
> structs to avoid having to deal with ABI breakages all the time: the policy
> is effectively encouraging people into better library design.
>
> pollutes the repository with commits announcing ABI changes that are
>> irrelevant after 2 cycles, as (code) diffs show that already (not
>> mentioning NEXT_ABI complexity and extra LOCs).
>>
>
> Fully agreed on NEXT_ABI, I never liked it at all.
>
> Maintaining LTS releases, and enforcing bug fixing in old LTS first,
>> upstreaming bugfixes is to me a much better approach to solve backwards
>> compatibility issues.
>>
>
> LTS releases could help the situation somewhat, but then again people tend
> to still want those new fancy things backported (you know, have the cake
> and eat it too) but that can't be done because of ABI breakage, so they're
> forced to run the latest version anyway.


> But this is probably another discussion.
>>
>
> Yup, changed subject to avoid mixing it up with the namespace discussion
> too much.


Yes, thanks for that
Marc


>
>
>         - Panu -
>
>

Re: [dpdk-dev] DPDK namespace

[Don Provan]

I can't believe you guys are seriously considering changing the prefix from rte_. That's a nightmare at the practical level, but it really doesn't make as much sense as some of you seem to think. I've always been really impressed that the names were prefixed with rte_ instead of dpdk_. While the primary goal was to provide dataplane capabilities, so much of the library -- mempools and rings, for example -- is general purpose, so a dpdk_ prefix wouldn't be appropriate for those routines, anyway.

The idea that everything in the library should be named "dpdk" is the same thinking that leads to the monolithic initialization function I've complained about before. I have major applications that use the DPDK library but do nothing at all with hardware, yet the library still insists on initializing the PCI components because there's no concept of using the library for anything other than receiving packets from hardware.

-don provan
dprovan@bivio.net

Re: [dpdk-dev] DPDK namespace

[Thomas Monjalon]

2016-04-11 16:10, Don Provan:
> I can't believe you guys are seriously considering changing the prefix from rte_. That's a nightmare at the practical level, but it really doesn't make as much sense as some of you seem to think. I've always been really impressed that the names were prefixed with rte_ instead of dpdk_. While the primary goal was to provide dataplane capabilities, so much of the library -- mempools and rings, for example -- is general purpose, so a dpdk_ prefix wouldn't be appropriate for those routines, anyway.
> 
> The idea that everything in the library should be named "dpdk" is the same thinking that leads to the monolithic initialization function I've complained about before. I have major applications that use the DPDK library but do nothing at all with hardware, yet the library still insists on initializing the PCI components because there's no concept of using the library for anything other than receiving packets from hardware.

It's good news to hear that DPDK allows you to develop major applications.
The BSD license allows to build a lot of various types of applications.
You are perfectly right to give your opinion and complain.
You would also be welcome to contribute and fix your concerns.