[dpdk-dev] DPDK namespace
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.
[dpdk-dev] DPDK namespace
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 at bivio.net
[dpdk-dev] DPDK namespace
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.
[dpdk-dev] DPDK namespace
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.
[dpdk-dev] DPDK namespace
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 >
[dpdk-dev] DPDK namespace
2016-04-07 11:33 GMT+02:00 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. 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] DPDK namespace
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
[dpdk-dev] DPDK namespace
On 6 April 2016 at 22:21, Dave Neary 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 >
[dpdk-dev] DPDK namespace
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
[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 >> 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 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 -
[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 >>> 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 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
[dpdk-dev] DPDK namespace
On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote: > On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona 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. 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
[dpdk-dev] DPDK namespace
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette > Sent: Wednesday, April 6, 2016 1:41 PM > To: Yuanhan Liu > Cc: Arnon Warshavsky ; Trahe, Fiona > ; Thomas Monjalon ; > dev at dpdk.org > Subject: Re: [dpdk-dev] DPDK namespace > > On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu > 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. --
[dpdk-dev] DPDK namespace
> -Original Message- > From: dev [mailto:dev-bounces at 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 at 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 > >> 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
[dpdk-dev] DPDK namespace
On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu 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
[dpdk-dev] DPDK namespace
On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona 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. /Arnon
[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!
[dpdk-dev] DPDK namespace
> -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_
