[dpdk-dev] next technical board meeting, 2017-04-06

[dpdk-dev] next technical board meeting, 2017-04-06

[Jerin Jacob]

Hello everyone,

A meeting of the DPDK technical board will occur next Thursday,
April 6th 2017 at 9am UTC?

The meeting takes place on the #dpdk-board channel on IRC.
This meeting is public, so anybody can join, see below for the agenda.

Jerin

1) Divergence between DPDK/Linux PF/VF implementations.

Discussions:
http://dpdk.org/ml/archives/dev/2017-March/060529.html
http://dpdk.org/ml/archives/dev/2017-March/060063.html
http://dpdk.org/ml/archives/dev/2016-December/053056.html

2) Representative for the DPDK governance board

3) Scope of cmdline and cfgfile libraries in DPDK.
Discuss the scope of cmdline and cfgfile libraries in DPDK
and see if we allow more libs like that (Keith proposed a CLI lib),
or we do not do more,
or do we target to replace them by better external equivalents?

4) Community questions/issues

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> 
> Hello everyone,
> 
> A meeting of the DPDK technical board will occur next Thursday,
> April 6th 2017 at 9am UTC?
> 
> The meeting takes place on the #dpdk-board channel on IRC.
> This meeting is public, so anybody can join, see below for the agenda.
> 
> Jerin
> 
> 1) Divergence between DPDK/Linux PF/VF implementations.
> 
> Discussions:
> http://dpdk.org/ml/archives/dev/2017-March/060529.html
> http://dpdk.org/ml/archives/dev/2017-March/060063.html
> http://dpdk.org/ml/archives/dev/2016-December/053056.html
> 
> 2) Representative for the DPDK governance board
> 
> 3) Scope of cmdline and cfgfile libraries in DPDK.
> Discuss the scope of cmdline and cfgfile libraries in DPDK
> and see if we allow more libs like that (Keith proposed a CLI lib),
> or we do not do more,
> or do we target to replace them by better external equivalents?

I would prefer not lumping cfgfile into the CLI discussion, we can have a different discussion on it later.

A couple of options for CLI are:

 1 - Include CLI in DPDK repo, then start converting apps to CLI.
     Keep or deprecate cmdline in the future.

 2 - Include CLI in DPDK repo, do not convert current APPs allow new apps to use cmdline or CLI.

 3 - Put CLI in a different repo in DPDK, do not convert apps to use CLI allow developers to decide if they want to use CLI.
     - I would like to be able to clone CLI into DPDK lib directory and build it as a DPDK library.
       This would mean updating common_base, lib/Makefile and rte.apps.mk using a patch or use common_base config option.
       Building CLI outside of DPDK as a external lib is not very easy for developers to manage.
       Could use a patch to include CLI into the DPDK build system, but just adding the configuration defaulted off is the cleaner way.

We talked about creating a new repo on DPDK.org and I am happy with it, just want it better integrated into DPDK as a first class library to make using it simpler and easier for developers.

Doing option #1 or #2 is my first choice, but option #3 is good if we can have it as a first class library.

> 
> 4) Community questions/issues
> 
> 
> 

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Olivier Matz]

Hi Keith,

On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:
> > On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > 
> > Hello everyone,
> > 
> > A meeting of the DPDK technical board will occur next Thursday,
> > April 6th 2017 at 9am UTC?
> > 
> > The meeting takes place on the #dpdk-board channel on IRC.
> > This meeting is public, so anybody can join, see below for the agenda.
> > 
> > Jerin
> > 
> > 1) Divergence between DPDK/Linux PF/VF implementations.
> > 
> > Discussions:
> > http://dpdk.org/ml/archives/dev/2017-March/060529.html
> > http://dpdk.org/ml/archives/dev/2017-March/060063.html
> > http://dpdk.org/ml/archives/dev/2016-December/053056.html
> > 
> > 2) Representative for the DPDK governance board
> > 
> > 3) Scope of cmdline and cfgfile libraries in DPDK.
> > Discuss the scope of cmdline and cfgfile libraries in DPDK
> > and see if we allow more libs like that (Keith proposed a CLI lib),
> > or we do not do more,
> > or do we target to replace them by better external equivalents?  
> 
> I would prefer not lumping cfgfile into the CLI discussion, we can have a different discussion on it later.
> 
> A couple of options for CLI are:
> 
>  1 - Include CLI in DPDK repo, then start converting apps to CLI.
>      Keep or deprecate cmdline in the future.

Before including the CLI lib and consider replacing the cmdline,
we should first all be convinced that:
- the app code will be more maintainable
- we will be able to replace all that we have (we won't loose feature)
- the api is well designed: we won't do the same job with another
  librte_cli2 next year

If we choose this option, I think the patch introducing the lib should
come with a significant amount of demonstration changes. I'm for instance
thinking about the recently introduced rte_flow that provide a contextual
completion.

Honnestly, I don't think it's worth doing it...

Another question that could be raised: should the cmdline/cfgfile/...
libraries be part of the public dpdk API? I think they could be
considered internal libraries. It would remove the need to preserve
API/ABI.

> 
>  2 - Include CLI in DPDK repo, do not convert current APPs allow new apps to use cmdline or CLI.

I think we should not have 2 libs for the same thing.
It's even more true for something that is out of scope of dpdk.



>  3 - Put CLI in a different repo in DPDK, do not convert apps to use CLI allow developers to decide if they want to use CLI.
>      - I would like to be able to clone CLI into DPDK lib directory and build it as a DPDK library.
>        This would mean updating common_base, lib/Makefile and rte.apps.mk using a patch or use common_base config option.
>        Building CLI outside of DPDK as a external lib is not very easy for developers to manage.
>        Could use a patch to include CLI into the DPDK build system, but just adding the configuration defaulted off is the cleaner way.

I think the proper way is to do/find a generic command line library,
and have it integrated into distros.

That say, the dpdk framework is missing some stuff to properly manage
the dependencies to external libs. We have this need not only for cli.



> 
> We talked about creating a new repo on DPDK.org and I am happy with it, just want it better integrated into DPDK as a first class library to make using it simpler and easier for developers.
> 
> Doing option #1 or #2 is my first choice, but option #3 is good if we can have it as a first class library.

What does first class mean?



Regards,
Olivier

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

> On Mar 30, 2017, at 10:05 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
> 
> Hi Keith,
> 
> On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> A meeting of the DPDK technical board will occur next Thursday,
>>> April 6th 2017 at 9am UTC?
>>> 
>>> The meeting takes place on the #dpdk-board channel on IRC.
>>> This meeting is public, so anybody can join, see below for the agenda.
>>> 
>>> Jerin
>>> 
>>> 1) Divergence between DPDK/Linux PF/VF implementations.
>>> 
>>> Discussions:
>>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
>>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
>>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
>>> 
>>> 2) Representative for the DPDK governance board
>>> 
>>> 3) Scope of cmdline and cfgfile libraries in DPDK.
>>> Discuss the scope of cmdline and cfgfile libraries in DPDK
>>> and see if we allow more libs like that (Keith proposed a CLI lib),
>>> or we do not do more,
>>> or do we target to replace them by better external equivalents?  
>> 
>> I would prefer not lumping cfgfile into the CLI discussion, we can have a different discussion on it later.
>> 
>> A couple of options for CLI are:
>> 
>> 1 - Include CLI in DPDK repo, then start converting apps to CLI.
>>     Keep or deprecate cmdline in the future.
> 
> Before including the CLI lib and consider replacing the cmdline,
> we should first all be convinced that:
> - the app code will be more maintainable

The app code for CLI IMO is far easier to maintain, but without others looking at the code and working with the code in an application it will be difficult for others to comment on this design. I feel it is obvious that CLI provides many new features and being dynamic at runtime then cmdline, but others need to work with the code and convert or write an application.

CLI uses known methods (arg/argv) and again I was able to reduce test-pmd from 12K lines to 4.5K lines of code, which I can provide a copy if someone wants to look at the conversion or just look at Pktgen.

As far as the CLI code I have tried to make it reasonable easy to maintain, but it can always be improved.

> - we will be able to replace all that we have (we won't loose feature)

I have attempted to keep most of the features in cmdline that I thought were the key features, but what are the features of cmdline? Someone needs to present a fair comparison to CLI and cmdline.

> - the api is well designed: we won't do the same job with another
>  librte_cli2 next year

I have attempted to provide a clean design, but without others looking and using the APIs how can we discuss this point honestly. As for a CLI-2 next year that will have to go thru the same process as CLI is going thru today and we then decide. To me this is not a real valid concern.

> 
> If we choose this option, I think the patch introducing the lib should
> come with a significant amount of demonstration changes. I'm for instance
> thinking about the recently introduced rte_flow that provide a contextual
> completion.

I did convert test-pmd to allow the developer to pick which CLI to use on the command line and I can provide that test case. The original cmdline code is not changed and could be the fall back. I know test-pmd with CLI needs to be tested a lot. I also will provide an example code for CLI, which I have written already and I can provide that code to someone now.

> 
> Honnestly, I don't think it's worth doing it...
> 
> Another question that could be raised: should the cmdline/cfgfile/...
> libraries be part of the public dpdk API? I think they could be
> considered internal libraries. It would remove the need to preserve
> API/ABI.

We can always decide any given library or API is not within the ABI. I am fine with not having CLI not use ABI as I feel we have abused the current ABI in DPDK today. It does not seem to really guaranty backward compatibility from release to release other then stating it changed from release to release. IMO the LTS is the only real ABI compatibility solution today.

> 
>> 
>> 2 - Include CLI in DPDK repo, do not convert current APPs allow new apps to use cmdline or CLI.
> 
> I think we should not have 2 libs for the same thing.
> It's even more true for something that is out of scope of dpdk.

I do not disagree, but giving an option is my first choice and this allows for backward compatibility IMO.

> 
> 
> 
>> 3 - Put CLI in a different repo in DPDK, do not convert apps to use CLI allow developers to decide if they want to use CLI.
>>     - I would like to be able to clone CLI into DPDK lib directory and build it as a DPDK library.
>>       This would mean updating common_base, lib/Makefile and rte.apps.mk using a patch or use common_base config option.
>>       Building CLI outside of DPDK as a external lib is not very easy for developers to manage.
>>       Could use a patch to include CLI into the DPDK build system, but just adding the configuration defaulted off is the cleaner way.
> 
> I think the proper way is to do/find a generic command line library,
> and have it integrated into distros.

I have looked for a reasonable solution for many years, if you find a simpler and easier solution I am willing to look at using it. Adding CLI to a distro is reasonable, but it is not standalone today it requires DPDK APIs, but I could be forced to convert it back to standalone which was not my goal.

> 
> That say, the dpdk framework is missing some stuff to properly manage
> the dependencies to external libs. We have this need not only for cli.

As much as I like a good 'sparking generality' as the next person, this is Not the case, Pktgen is another real case and I am sure others. Besides I think we should deal with external builds with my comment below.

> 
> 
> 
>> 
>> We talked about creating a new repo on DPDK.org and I am happy with it, just want it better integrated into DPDK as a first class library to make using it simpler and easier for developers.
>> 
>> Doing option #1 or #2 is my first choice, but option #3 is good if we can have it as a first class library.
> 
> What does first class mean?

First class means allowing CLI or other applications or libraries to be easily included into DPDK using the standard internal build system.

Take Pktgen it is one of the must used applications for DPDK today, but it has to be built outside of DPDK using DPDK external build support. The external build support IMO could be dropped (less code to deal with) and just allow someone to clone a repo into a DPDK directory enable the config and build DPDK normally using the standard make options. This allows all applications to locate the common includes and libraries without having to add code to the Makefile to locate includes and libraries as they are all contained in the standard DPDK location.

We can add automatic support for new config files into the build system without having to edit DPDK files to make it build.


My Soap box comment:
   I think we are limiting DPDK’s growth by only focusing on a few new PMDs and reworking the existing code. We need to look forward and grow DPDK as a community to get more people involved in adding more applications and new designs. I believe DPDK.org needs to be a bigger community and not just a I/O library called DPDK. We need to actively move the organization to include more then just a high speed I/O library. Some will focus on DPDK and others will focus on providing a higher level applications, libraries and features.

> 
> 
> 
> Regards,
> Olivier

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Jay Rolette]

On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
wrote:

<snip>
>
> My Soap box comment:
>    I think we are limiting DPDK’s growth by only focusing on a few new
> PMDs and reworking the existing code. We need to look forward and grow DPDK
> as a community to get more people involved in adding more applications and
> new designs. I believe DPDK.org needs to be a bigger community and not just
> a I/O library called DPDK. We need to actively move the organization to
> include more then just a high speed I/O library. Some will focus on DPDK
> and others will focus on providing a higher level applications, libraries
> and features.
>
> Regards,
> Keith
>

Yes!

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Dumitrescu, Cristian]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
> Sent: Thursday, March 30, 2017 5:03 PM
> To: Wiles, Keith <keith.wiles@intel.com>
> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
> 
> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
> wrote:
> 
> <snip>
> >
> > My Soap box comment:
> >    I think we are limiting DPDK’s growth by only focusing on a few new
> > PMDs and reworking the existing code. We need to look forward and grow
> DPDK
> > as a community to get more people involved in adding more applications
> and
> > new designs. I believe DPDK.org needs to be a bigger community and not
> just
> > a I/O library called DPDK. We need to actively move the organization to
> > include more then just a high speed I/O library. Some will focus on DPDK
> > and others will focus on providing a higher level applications, libraries
> > and features.
> >
> > Regards,
> > Keith
> >
> 
> Yes!

+1

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Olivier Matz]

Hi,

On Thu, 30 Mar 2017 15:51:48 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:
> > On Mar 30, 2017, at 10:05 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
> > 
> > Hi Keith,
> > 
> > On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:  
> >>> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >>> 
> >>> Hello everyone,
> >>> 
> >>> A meeting of the DPDK technical board will occur next Thursday,
> >>> April 6th 2017 at 9am UTC?
> >>> 
> >>> The meeting takes place on the #dpdk-board channel on IRC.
> >>> This meeting is public, so anybody can join, see below for the agenda.
> >>> 
> >>> Jerin
> >>> 
> >>> 1) Divergence between DPDK/Linux PF/VF implementations.
> >>> 
> >>> Discussions:
> >>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
> >>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
> >>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
> >>> 
> >>> 2) Representative for the DPDK governance board
> >>> 
> >>> 3) Scope of cmdline and cfgfile libraries in DPDK.
> >>> Discuss the scope of cmdline and cfgfile libraries in DPDK
> >>> and see if we allow more libs like that (Keith proposed a CLI lib),
> >>> or we do not do more,
> >>> or do we target to replace them by better external equivalents?    
> >> 
> >> I would prefer not lumping cfgfile into the CLI discussion, we can have a different discussion on it later.
> >> 
> >> A couple of options for CLI are:
> >> 
> >> 1 - Include CLI in DPDK repo, then start converting apps to CLI.
> >>     Keep or deprecate cmdline in the future.  
> > 
> > Before including the CLI lib and consider replacing the cmdline,
> > we should first all be convinced that:
> > - the app code will be more maintainable  
> 
> The app code for CLI IMO is far easier to maintain, but without others looking at the code and working with the code in an application it will be difficult for others to comment on this design. I feel it is obvious that CLI provides many new features and being dynamic at runtime then cmdline, but others need to work with the code and convert or write an application.
> 
> CLI uses known methods (arg/argv) and again I was able to reduce test-pmd from 12K lines to 4.5K lines of code, which I can provide a copy if someone wants to look at the conversion or just look at Pktgen.
> 
> As far as the CLI code I have tried to make it reasonable easy to maintain, but it can always be improved.

That's exactly what I am requesting. If it appears that the testpmd
code is smaller and clearer with the new cli lib, it's one good argument.


> > - we will be able to replace all that we have (we won't loose feature)  
> 
> I have attempted to keep most of the features in cmdline that I thought were the key features, but what are the features of cmdline? Someone needs to present a fair comparison to CLI and cmdline.

I think "someone" should be "you" ;) (with the help of community).
If you're willing to replace librte_cmdline, you need to present in how
librte_cli is better.


[...]

> >> We talked about creating a new repo on DPDK.org and I am happy with it, just want it better integrated into DPDK as a first class library to make using it simpler and easier for developers.
> >> 
> >> Doing option #1 or #2 is my first choice, but option #3 is good if we can have it as a first class library.  
> > 
> > What does first class mean?  
> 
> First class means allowing CLI or other applications or libraries to be easily included into DPDK using the standard internal build system.
> 
> Take Pktgen it is one of the must used applications for DPDK today, but it has to be built outside of DPDK using DPDK external build support. The external build support IMO could be dropped (less code to deal with) and just allow someone to clone a repo into a DPDK directory enable the config and build DPDK normally using the standard make options. This allows all applications to locate the common includes and libraries without having to add code to the Makefile to locate includes and libraries as they are all contained in the standard DPDK location.

Here, you are just requesting to enhance the external build
support, right? Well, why not.

Although it would probably be better to let the application use
its own Makefiles. For that, we need the DPDK to provide the proper infos
(include path, lib path, ...), something like pkg-config.


> 
> We can add automatic support for new config files into the build system without having to edit DPDK files to make it build.
> 
> 
> My Soap box comment:
>    I think we are limiting DPDK’s growth by only focusing on a few new PMDs and reworking the existing code. We need to look forward and grow DPDK as a community to get more people involved in adding more applications and new designs. I believe DPDK.org needs to be a bigger community and not just a I/O library called DPDK. We need to actively move the organization to include more then just a high speed I/O library. Some will focus on DPDK and others will focus on providing a higher level applications, libraries and features.

Sorry, I completly disagree with that vision. I think the scope of dpdk
should be more focused.

Today, when someone adds a feature, (s)he sometimes updates eal, or mbuf,
or any core layer required for its need. It can be just a hack, no matter
if the feature works. I have many examples like this.

This makes any rework/enhancement of core libs painful.
Having separated core libs would encourage people to submit proper
generic enhancements, to have stable APIs.

Having more and more code in dpdk will confuse the new users.
I'm also convinced it will decrease overall code quality.

It will increase traffic on the mailing list.

It goes against the principle of "keep it simple, small". You say you
cannot find any good and public cli library. Putting it in the dpdk would
solve your problem but would let the problem open for the rest of the world:
"there is still no good and public cli library".

If you put your lib in a separate rep, with no deps to dpdk, it will become
usable for everyone... therefore it will bring more people willing to help
you to enhance this library... enhancing dpdk indirectly.


My 2 cents,
Olivier

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Dumitrescu, Cristian]

> > My Soap box comment:
> >    I think we are limiting DPDK’s growth by only focusing on a few new PMDs
> and reworking the existing code. We need to look forward and grow DPDK as
> a community to get more people involved in adding more applications and
> new designs. I believe DPDK.org needs to be a bigger community and not
> just a I/O library called DPDK. We need to actively move the organization to
> include more then just a high speed I/O library. Some will focus on DPDK and
> others will focus on providing a higher level applications, libraries and
> features.
> 
> Sorry, I completly disagree with that vision. I think the scope of dpdk
> should be more focused.
> 
> Today, when someone adds a feature, (s)he sometimes updates eal, or
> mbuf,
> or any core layer required for its need. It can be just a hack, no matter
> if the feature works. I have many examples like this.
> 
> This makes any rework/enhancement of core libs painful.
> Having separated core libs would encourage people to submit proper
> generic enhancements, to have stable APIs.
> 

Hi Olivier,

I think I understand your problem (reduce the effort of updating the "core" libs), but I also think your proposed solution (ignore all the other libs and apps that are being broken by the change) is wrong.

When faced with a change that has ripple effect everywhere, why not post an RFC and ask for help from the other maintainers to share the burden?

Regards,
Cristian

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

> On Mar 31, 2017, at 3:52 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
> 
> Hi,
> 
> On Thu, 30 Mar 2017 15:51:48 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>> On Mar 30, 2017, at 10:05 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
>>> 
>>> Hi Keith,
>>> 
>>> On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <keith.wiles@intel.com> wrote:  
>>>>> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>>>>> 
>>>>> Hello everyone,
>>>>> 
>>>>> A meeting of the DPDK technical board will occur next Thursday,
>>>>> April 6th 2017 at 9am UTC?
>>>>> 
>>>>> The meeting takes place on the #dpdk-board channel on IRC.
>>>>> This meeting is public, so anybody can join, see below for the agenda.
>>>>> 
>>>>> Jerin
>>>>> 
>>>>> 1) Divergence between DPDK/Linux PF/VF implementations.
>>>>> 
>>>>> Discussions:
>>>>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
>>>>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
>>>>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
>>>>> 
>>>>> 2) Representative for the DPDK governance board
>>>>> 
>>>>> 3) Scope of cmdline and cfgfile libraries in DPDK.
>>>>> Discuss the scope of cmdline and cfgfile libraries in DPDK
>>>>> and see if we allow more libs like that (Keith proposed a CLI lib),
>>>>> or we do not do more,
>>>>> or do we target to replace them by better external equivalents?    
>>>> 
>>>> I would prefer not lumping cfgfile into the CLI discussion, we can have a different discussion on it later.
>>>> 
>>>> A couple of options for CLI are:
>>>> 
>>>> 1 - Include CLI in DPDK repo, then start converting apps to CLI.
>>>>    Keep or deprecate cmdline in the future.  
>>> 
>>> Before including the CLI lib and consider replacing the cmdline,
>>> we should first all be convinced that:
>>> - the app code will be more maintainable  
>> 
>> The app code for CLI IMO is far easier to maintain, but without others looking at the code and working with the code in an application it will be difficult for others to comment on this design. I feel it is obvious that CLI provides many new features and being dynamic at runtime then cmdline, but others need to work with the code and convert or write an application.
>> 
>> CLI uses known methods (arg/argv) and again I was able to reduce test-pmd from 12K lines to 4.5K lines of code, which I can provide a copy if someone wants to look at the conversion or just look at Pktgen.
>> 
>> As far as the CLI code I have tried to make it reasonable easy to maintain, but it can always be improved.
> 
> That's exactly what I am requesting. If it appears that the testpmd
> code is smaller and clearer with the new cli lib, it's one good argument.

> 
> 
>>> - we will be able to replace all that we have (we won't loose feature)  
>> 
>> I have attempted to keep most of the features in cmdline that I thought were the key features, but what are the features of cmdline? Someone needs to present a fair comparison to CLI and cmdline.
> 
> I think "someone" should be "you" ;) (with the help of community).
> If you're willing to replace librte_cmdline, you need to present in how
> librte_cli is better.
> 

I have documented a number of reasons why CLI is better in a number of posts here is the start of the thread again for your reading. It may not contain a list of features, but neither does cmdline. Please have another read and I will look at providing a set of features.

http://dpdk.org/ml/archives/dev/2017-March/059951.html

Then maybe you can add the feature set of cmdline.


> 
> [...]
> 
>>>> We talked about creating a new repo on DPDK.org and I am happy with it, just want it better integrated into DPDK as a first class library to make using it simpler and easier for developers.
>>>> 
>>>> Doing option #1 or #2 is my first choice, but option #3 is good if we can have it as a first class library.  
>>> 
>>> What does first class mean?  
>> 
>> First class means allowing CLI or other applications or libraries to be easily included into DPDK using the standard internal build system.
>> 
>> Take Pktgen it is one of the must used applications for DPDK today, but it has to be built outside of DPDK using DPDK external build support. The external build support IMO could be dropped (less code to deal with) and just allow someone to clone a repo into a DPDK directory enable the config and build DPDK normally using the standard make options. This allows all applications to locate the common includes and libraries without having to add code to the Makefile to locate includes and libraries as they are all contained in the standard DPDK location.
> 
> Here, you are just requesting to enhance the external build
> support, right? Well, why not.

I am not requesting to enhance the external build, I am suggesting we remove it as it is not well supported or very useful to developers. Again I would like to be able to clone a library, application or what ever into the main DPDK tree and build using the internal build system. Using the internal build system makes a lot of sense as it is possible to allow developers to pull in new features from other repos and still get the support from the primary build system.

> 
> Although it would probably be better to let the application use
> its own Makefiles. For that, we need the DPDK to provide the proper infos
> (include path, lib path, ...), something like pkg-config.

The applications maybe and maybe not all, but example applications and new libraries no. Being able to build a library using the primary build is very reasonable and very useful to the developer writing a new example or library for DPDK.

The comment about packaging is just trying to confuse the issues here, as anyone wanting to release his library in a distro with DPDK would need to create these files and information anyway. This does not mean the primary DPDK distro needs to change. 

> 
> 
>> 
>> We can add automatic support for new config files into the build system without having to edit DPDK files to make it build.
>> 
>> 
>> My Soap box comment:
>>   I think we are limiting DPDK’s growth by only focusing on a few new PMDs and reworking the existing code. We need to look forward and grow DPDK as a community to get more people involved in adding more applications and new designs. I believe DPDK.org needs to be a bigger community and not just a I/O library called DPDK. We need to actively move the organization to include more then just a high speed I/O library. Some will focus on DPDK and others will focus on providing a higher level applications, libraries and features.
> 
> Sorry, I completly disagree with that vision. I think the scope of dpdk
> should be more focused.
> 
> Today, when someone adds a feature, (s)he sometimes updates eal, or mbuf,
> or any core layer required for its need. It can be just a hack, no matter
> if the feature works. I have many examples like this.

I am talking about a library that does not effect the rest of DPDK and effecting the core code is not something I want here. The CLI would not effect the core code as you are pointing out. Besides we can always reject the changes to the core code if that happens, right?

> 
> This makes any rework/enhancement of core libs painful.
> Having separated core libs would encourage people to submit proper
> generic enhancements, to have stable APIs.

This is a non-point as we are not talking about this type of core change.

> 
> Having more and more code in dpdk will confuse the new users.
> I'm also convinced it will decrease overall code quality.

You are kidding right? More code confuses the developer, OK then lets reduce the code of the Linux kernel, FreeBSD, OVS, … remove cmdline and the examples and test-pmd and many others as these are not the code code of DPDK. This line of thinking does not make any sense.

You are arbitrarily limiting what DPDK and the organization can be just for the sake of too much code or helpful libraries or making it easy for developer to add their useful libraries.

Side note: We can split up DPDK into multiple repos to get to the core code set then you can subscribe to that one email list for that repo and ignore the rest of the world or DPDK in this case.

> 
> It will increase traffic on the mailing list.

Who cares this is what filters/folders are all about in email readers. We can always have more email list and you do not need to subscribe to any email list except the core DPDK code list.

> 
> It goes against the principle of "keep it simple, small". You say you
> cannot find any good and public cli library. Putting it in the dpdk would
> solve your problem but would let the problem open for the rest of the world:
> "there is still no good and public cli library”.

It still keeps the core code small and simple you are not thinking correctly here. Well you go and look your self for a good CLI and let me know if you find one that will work. I have looked at a lot of them over the years with very different set of requirements, but I did not find one.

> 
> If you put your lib in a separate rep, with no deps to dpdk, it will become
> usable for everyone... therefore it will bring more people willing to help
> you to enhance this library... enhancing dpdk indirectly.

Who stated I wanted my CLI to be usable by anything except DPDK, that is the reason it uses DPDK APIs. I could convert it, but why would I want to? I wanted to improve DPDK CLI and usage model for the DPDK developer not everyone on the planet.

As someone stated someplace ‘if something does not grow it dies’ or something like that and I want DPDK to grow. It does not mean it needs to move away from its core values or make wild changes to the core code for some library. Changes happen to the core code only want it meets our core values as I have seen a number of rejections as not providing value to the core code if changing the core code.

> 
> 
> My 2 cents,
> Olivier

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

Here is a few advantages to CLI:

A couple big advantages I see are:
  - CLI supports commands, files, aliases, directories.
    - The alias command is just a string using a simple substitution support for other other commands similar to the bash shell like alias commands.
    - Files can be static or dynamic information, can be changed on the fly and saved for later. The file is backed with a simple function callback to allow the developer to update the content or not.
  - Added support for color and cursor movement APIs similar to Pktgen if needed by the developer.
  - It is a work alike replacement for cmdline library. Both cmdline and CLI can be used in the same application if care is taken.
  - Uses a simple fake like directory layout for command and files. Allowing for command hierarchy as path to the command can allow for specific targets to be identified without having to state it on the command line. 
  - Has auto-complete for commands, similar to Unix/Linux autocomplete and provides support for command option help as well.
  - Callback functions for commands are simply just argc/argv like functions. The CLI does not convert arguments for the user, it is up to the developer to decode the argv[] values.
    - Most of the arguments converted in the current cmdline are difficult to use or not required as the developer just picks string type and does the conversion himself.
  - Dynamically be able to add and remove commands, directories, files and aliases, does not need to be statically compiled into the application.
  - No weird structures in the code and reduces the line count for testpmd from 11K to 4K lines. I convert testpmd to have both CMDLINE and CLI with a command line option.
  - Two methods to parse command lines, first is the standard argc/argv method in the function. The second method is to use a map of strings with simple printf like formatting to detect which command line the user typed. An ID value it returned to the used to indicate which mapping string was found to make the command line to be used in a switch statement.
  - Central help support if needed (optional).


Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Stephen Hemminger]

On Thu, 30 Mar 2017 18:09:04 +0000
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:

> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
> > Sent: Thursday, March 30, 2017 5:03 PM
> > To: Wiles, Keith <keith.wiles@intel.com>
> > Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
> > <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
> > Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
> > 
> > On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
> > wrote:
> > 
> > <snip>  
> > >
> > > My Soap box comment:
> > >    I think we are limiting DPDK’s growth by only focusing on a few new
> > > PMDs and reworking the existing code. We need to look forward and grow  
> > DPDK  
> > > as a community to get more people involved in adding more applications  
> > and  
> > > new designs. I believe DPDK.org needs to be a bigger community and not  
> > just  
> > > a I/O library called DPDK. We need to actively move the organization to
> > > include more then just a high speed I/O library. Some will focus on DPDK
> > > and others will focus on providing a higher level applications, libraries
> > > and features.
> > >
> > > Regards,
> > > Keith
> > >  
> > 
> > Yes!  
> 
> +1

Yes but it needs some architecture. Sorry but the features flying in are
just addressing single use cases and have no unifying model.

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

> On Apr 3, 2017, at 2:51 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> On Thu, 30 Mar 2017 18:09:04 +0000
> "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
> 
>>> -----Original Message-----
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
>>> Sent: Thursday, March 30, 2017 5:03 PM
>>> To: Wiles, Keith <keith.wiles@intel.com>
>>> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
>>> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
>>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
>>> 
>>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
>>> wrote:
>>> 
>>> <snip>  
>>>> 
>>>> My Soap box comment:
>>>>   I think we are limiting DPDK’s growth by only focusing on a few new
>>>> PMDs and reworking the existing code. We need to look forward and grow  
>>> DPDK  
>>>> as a community to get more people involved in adding more applications  
>>> and  
>>>> new designs. I believe DPDK.org needs to be a bigger community and not  
>>> just  
>>>> a I/O library called DPDK. We need to actively move the organization to
>>>> include more then just a high speed I/O library. Some will focus on DPDK
>>>> and others will focus on providing a higher level applications, libraries
>>>> and features.
>>>> 
>>>> Regards,
>>>> Keith
>>>> 
>>> 
>>> Yes!  
>> 
>> +1
> 
> Yes but it needs some architecture. Sorry but the features flying in are
> just addressing single use cases and have no unifying model.

Stephen,

Not sure I fully understand your comment here. I was only adding features here, the architecture would be a much longer doc. I was working more on the docs this weekend, but did not make a lot of progress (I am not the best doc writer in the world). Posting the cli.rst file to the list I am sure would be frowned on, but I did include them in the Pktgen version of the code.

I would be great if you could explain your views on a architecture for a CLI.

To me a CLI should provide a clean and easy way to add commands for the developer, but at the same time provide simple ways to execute these commands. Now creating a user level design to make it easy for the user to navigate or use the commands that one is very broad as everyone has his own ideas on what is simple and easy to use.

Some CLIs attempt to provide a very strict user level model and it may make the developer user model easier. My goal was to give a similar user level model to CLI as cmdline, but provide a much easier developer level model.

Some CLIs attempt to provide the most generic solution to create any type of user level model, these are normally very complex and difficult for the developer to use. The developer in these cases have to create that user level model, which we all know can be very ugly for the user.  The cmdline attempts to handle all of the conversion of the types and provides a strict developer model. The commands are strict in the sense they are not flexible by allowing for different number of arguments/type to the same basic command. We have added things like kvargs and I have added to Pktgen a argc/argv method. These then require the developer to decode the argv strings. The cmdline design I was always looking for ways to work around the developer model as it was difficult to use with complex command, so in CLI I removed that restriction for the better I think.

CLI provides a directory like command layout with directories, command, files and alias commands. The user level model is very similar to cmdline, but the developer model is very simple and very fast to add a new command and complex commands as well.

Using CLI you can make it look like cmdline from the user view point or you can use the directory structure. I find it easier to group commands and function in directories, but YMMV.

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Stephen Hemminger]

On Mon, 3 Apr 2017 22:53:06 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:

> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> > 
> > On Thu, 30 Mar 2017 18:09:04 +0000
> > "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
> >   
> >>> -----Original Message-----
> >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
> >>> Sent: Thursday, March 30, 2017 5:03 PM
> >>> To: Wiles, Keith <keith.wiles@intel.com>
> >>> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
> >>> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
> >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
> >>> 
> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
> >>> wrote:
> >>> 
> >>> <snip>    
> >>>> 
> >>>> My Soap box comment:
> >>>>   I think we are limiting DPDK’s growth by only focusing on a few new
> >>>> PMDs and reworking the existing code. We need to look forward and grow    
> >>> DPDK    
> >>>> as a community to get more people involved in adding more applications    
> >>> and    
> >>>> new designs. I believe DPDK.org needs to be a bigger community and not    
> >>> just    
> >>>> a I/O library called DPDK. We need to actively move the organization to
> >>>> include more then just a high speed I/O library. Some will focus on DPDK
> >>>> and others will focus on providing a higher level applications, libraries
> >>>> and features.
> >>>> 
> >>>> Regards,
> >>>> Keith
> >>>>   
> >>> 
> >>> Yes!    
> >> 
> >> +1  
> > 
> > Yes but it needs some architecture. Sorry but the features flying in are
> > just addressing single use cases and have no unifying model.  
> 
> Stephen,
> 
> Not sure I fully understand your comment here. I was only adding features here, the architecture would be a much longer doc. I was working more on the docs this weekend, but did not make a lot of progress (I am not the best doc writer in the world). Posting the cli.rst file to the list I am sure would be frowned on, but I did include them in the Pktgen version of the code.
> 
> I would be great if you could explain your views on a architecture for a CLI.
> 
> To me a CLI should provide a clean and easy way to add commands for the developer, but at the same time provide simple ways to execute these commands. Now creating a user level design to make it easy for the user to navigate or use the commands that one is very broad as everyone has his own ideas on what is simple and easy to use.
> 
> Some CLIs attempt to provide a very strict user level model and it may make the developer user model easier. My goal was to give a similar user level model to CLI as cmdline, but provide a much easier developer level model.
> 
> Some CLIs attempt to provide the most generic solution to create any type of user level model, these are normally very complex and difficult for the developer to use. The developer in these cases have to create that user level model, which we all know can be very ugly for the user.  The cmdline attempts to handle all of the conversion of the types and provides a strict developer model. The commands are strict in the sense they are not flexible by allowing for different number of arguments/type to the same basic command. We have added things like kvargs and I have added to Pktgen a argc/argv method. These then require the developer to decode the argv strings. The cmdline design I was always looking for ways to work around the developer model as it was difficult to use with complex command, so in CLI I removed that restriction for the better I think.
> 
> CLI provides a directory like command layout with directories, command, files and alias commands. The user level model is very similar to cmdline, but the developer model is very simple and very fast to add a new command and complex commands as well.
> 
> Using CLI you can make it look like cmdline from the user view point or you can use the directory structure. I find it easier to group commands and function in directories, but YMMV.
> 
> Regards,
> Keith
> 

My concern is that DPDK is growing because of lots of contributions (good) but that
each contribution only thinks of their own narrow use case. This is because as it says on the
web page, DPDK is not a complete product. VPP (and others) are a more of a product and each
feature is more integrated. Think of Gnome and KDE, they strive to provide a complete
desktop experience and each application is part of that. DPDK does not have a really
strong over arching vision and mission which new contributions can be judged against.

Maybe a better example is some of the language class libraries. They provide broad set
of tools but the all play well together. Right now DPDK is not consistent. It is possible
to build something complex like a NAT IPv6 load balancer and firewall with QoS. But
it is not obvious, complete or easy.

So my concerns are not about the CLI. It is just that CLI is just an example of an individual function that stands alone. Having more tools is good, but if they don't
fit together easily, then more tools doesn't help.

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Vincent Jardin]

Le 4 avril 2017 4:28:47 AM Stephen Hemminger <stephen@networkplumber.org> a 
écrit :

> On Mon, 3 Apr 2017 22:53:06 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger 
>> <stephen@networkplumber.org> wrote:
>> >
>> > On Thu, 30 Mar 2017 18:09:04 +0000
>> > "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
>> >
>> >>> -----Original Message-----
>> >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
>> >>> Sent: Thursday, March 30, 2017 5:03 PM
>> >>> To: Wiles, Keith <keith.wiles@intel.com>
>> >>> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
>> >>> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
>> >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
>> >>>
>> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
>> >>> wrote:
>> >>>
>> >>> <snip>
>> >>>>
>> >>>> My Soap box comment:
>> >>>>   I think we are limiting DPDK’s growth by only focusing on a few new
>> >>>> PMDs and reworking the existing code. We need to look forward and grow
>> >>> DPDK
>> >>>> as a community to get more people involved in adding more applications
>> >>> and
>> >>>> new designs. I believe DPDK.org needs to be a bigger community and not
>> >>> just
>> >>>> a I/O library called DPDK. We need to actively move the organization to
>> >>>> include more then just a high speed I/O library. Some will focus on DPDK
>> >>>> and others will focus on providing a higher level applications, libraries
>> >>>> and features.
>> >>>>
>> >>>> Regards,
>> >>>> Keith
>> >>>>
>> >>>
>> >>> Yes!
>> >>
>> >> +1
>> >
>> > Yes but it needs some architecture. Sorry but the features flying in are
>> > just addressing single use cases and have no unifying model.
>>
>> Stephen,
>>
>> Not sure I fully understand your comment here. I was only adding features 
>> here, the architecture would be a much longer doc. I was working more on 
>> the docs this weekend, but did not make a lot of progress (I am not the 
>> best doc writer in the world). Posting the cli.rst file to the list I am 
>> sure would be frowned on, but I did include them in the Pktgen version of 
>> the code.
>>
>> I would be great if you could explain your views on a architecture for a CLI.
>>
>> To me a CLI should provide a clean and easy way to add commands for the 
>> developer, but at the same time provide simple ways to execute these 
>> commands. Now creating a user level design to make it easy for the user to 
>> navigate or use the commands that one is very broad as everyone has his own 
>> ideas on what is simple and easy to use.
>>
>> Some CLIs attempt to provide a very strict user level model and it may make 
>> the developer user model easier. My goal was to give a similar user level 
>> model to CLI as cmdline, but provide a much easier developer level model.
>>
>> Some CLIs attempt to provide the most generic solution to create any type 
>> of user level model, these are normally very complex and difficult for the 
>> developer to use. The developer in these cases have to create that user 
>> level model, which we all know can be very ugly for the user.  The cmdline 
>> attempts to handle all of the conversion of the types and provides a strict 
>> developer model. The commands are strict in the sense they are not flexible 
>> by allowing for different number of arguments/type to the same basic 
>> command. We have added things like kvargs and I have added to Pktgen a 
>> argc/argv method. These then require the developer to decode the argv 
>> strings. The cmdline design I was always looking for ways to work around 
>> the developer model as it was difficult to use with complex command, so in 
>> CLI I removed that restriction for the better I think.
>>
>> CLI provides a directory like command layout with directories, command, 
>> files and alias commands. The user level model is very similar to cmdline, 
>> but the developer model is very simple and very fast to add a new command 
>> and complex commands as well.
>>
>> Using CLI you can make it look like cmdline from the user view point or you 
>> can use the directory structure. I find it easier to group commands and 
>> function in directories, but YMMV.
>>
>> Regards,
>> Keith
>>
>
> My concern is that DPDK is growing because of lots of contributions (good) 
> but that
> each contribution only thinks of their own narrow use case. This is because 
> as it says on the
> web page, DPDK is not a complete product. VPP (and others) are a more of a 
> product and each
> feature is more integrated. Think of Gnome and KDE, they strive to provide 
> a complete
> desktop experience and each application is part of that. DPDK does not have 
> a really
> strong over arching vision and mission which new contributions can be 
> judged against.
>
> Maybe a better example is some of the language class libraries. They 
> provide broad set
> of tools but the all play well together. Right now DPDK is not consistent. 
> It is possible
> to build something complex like a NAT IPv6 load balancer and firewall with 
> QoS. But
> it is not obvious, complete or easy.
>
> So my concerns are not about the CLI. It is just that CLI is just an 
> example of an individual function that stands alone. Having more tools is 
> good, but if they don't
> fit together easily, then more tools doesn't help.

The goal is beyond DPDK : we need a wide set of community building 
applications  (VPP vs OVS-DPDK vs Lagopus vs xyz).

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Wiles, Keith]

> On Apr 4, 2017, at 12:01 AM, Vincent Jardin <vincent.jardin@6wind.com> wrote:
> 
> 
> 
> Le 4 avril 2017 4:28:47 AM Stephen Hemminger <stephen@networkplumber.org> a écrit :
> 
>> On Mon, 3 Apr 2017 22:53:06 +0000
>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>> 
>>> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>> >
>>> > On Thu, 30 Mar 2017 18:09:04 +0000
>>> > "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
>>> >
>>> >>> -----Original Message-----
>>> >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette
>>> >>> Sent: Thursday, March 30, 2017 5:03 PM
>>> >>> To: Wiles, Keith <keith.wiles@intel.com>
>>> >>> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
>>> >>> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org; techboard@dpdk.org
>>> >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
>>> >>>
>>> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles@intel.com>
>>> >>> wrote:
>>> >>>
>>> >>> <snip>
>>> >>>>
>>> >>>> My Soap box comment:
>>> >>>>   I think we are limiting DPDK’s growth by only focusing on a few new
>>> >>>> PMDs and reworking the existing code. We need to look forward and grow
>>> >>> DPDK
>>> >>>> as a community to get more people involved in adding more applications
>>> >>> and
>>> >>>> new designs. I believe DPDK.org needs to be a bigger community and not
>>> >>> just
>>> >>>> a I/O library called DPDK. We need to actively move the organization to
>>> >>>> include more then just a high speed I/O library. Some will focus on DPDK
>>> >>>> and others will focus on providing a higher level applications, libraries
>>> >>>> and features.
>>> >>>>
>>> >>>> Regards,
>>> >>>> Keith
>>> >>>>
>>> >>>
>>> >>> Yes!
>>> >>
>>> >> +1
>>> >
>>> > Yes but it needs some architecture. Sorry but the features flying in are
>>> > just addressing single use cases and have no unifying model.
>>> 
>>> Stephen,
>>> 
>>> Not sure I fully understand your comment here. I was only adding features here, the architecture would be a much longer doc. I was working more on the docs this weekend, but did not make a lot of progress (I am not the best doc writer in the world). Posting the cli.rst file to the list I am sure would be frowned on, but I did include them in the Pktgen version of the code.
>>> 
>>> I would be great if you could explain your views on a architecture for a CLI.
>>> 
>>> To me a CLI should provide a clean and easy way to add commands for the developer, but at the same time provide simple ways to execute these commands. Now creating a user level design to make it easy for the user to navigate or use the commands that one is very broad as everyone has his own ideas on what is simple and easy to use.
>>> 
>>> Some CLIs attempt to provide a very strict user level model and it may make the developer user model easier. My goal was to give a similar user level model to CLI as cmdline, but provide a much easier developer level model.
>>> 
>>> Some CLIs attempt to provide the most generic solution to create any type of user level model, these are normally very complex and difficult for the developer to use. The developer in these cases have to create that user level model, which we all know can be very ugly for the user.  The cmdline attempts to handle all of the conversion of the types and provides a strict developer model. The commands are strict in the sense they are not flexible by allowing for different number of arguments/type to the same basic command. We have added things like kvargs and I have added to Pktgen a argc/argv method. These then require the developer to decode the argv strings. The cmdline design I was always looking for ways to work around the developer model as it was difficult to use with complex command, so in CLI I removed that restriction for the better I think.
>>> 
>>> CLI provides a directory like command layout with directories, command, files and alias commands. The user level model is very similar to cmdline, but the developer model is very simple and very fast to add a new command and complex commands as well.
>>> 
>>> Using CLI you can make it look like cmdline from the user view point or you can use the directory structure. I find it easier to group commands and function in directories, but YMMV.
>>> 
>>> Regards,
>>> Keith
>>> 
>> 
>> My concern is that DPDK is growing because of lots of contributions (good) but that
>> each contribution only thinks of their own narrow use case. This is because as it says on the
>> web page, DPDK is not a complete product. VPP (and others) are a more of a product and each
>> feature is more integrated. Think of Gnome and KDE, they strive to provide a complete
>> desktop experience and each application is part of that. DPDK does not have a really
>> strong over arching vision and mission which new contributions can be judged against.
>> 
>> Maybe a better example is some of the language class libraries. They provide broad set
>> of tools but the all play well together. Right now DPDK is not consistent. It is possible
>> to build something complex like a NAT IPv6 load balancer and firewall with QoS. But
>> it is not obvious, complete or easy.
>> 
>> So my concerns are not about the CLI. It is just that CLI is just an example of an individual function that stands alone. Having more tools is good, but if they don't
>> fit together easily, then more tools doesn't help.
> 
> The goal is beyond DPDK : we need a wide set of community building applications  (VPP vs OVS-DPDK vs Lagopus vs xyz).

To answer Stephen and Vincent, DPDK does need better building blocks to build better applications. The goal of CLI was to help provide that building block as a better solution to cmdline. The primary goal for CLI was to provide a cleaner simpler solution to allow developers to build application as you two are pointing out.

It has been stated in emails and other places that DPDK should not contain these higher level applications or at least that is my opinion from the comments others have make in the past. I feel DPDK can also contain higher level applications like VPP, OVS, NAT, …, which allows us to create better applications. In some cases we use existing designs like VPP, OVS,… to create better applications, but many other applications are not easy to build with DPDK or any other design. DPDK.org needs to encourage these designs using DPDK and we have failed to create these applications in DPDK IMO because we are not helping developers to build these application.

Stephen and Vincent if you want good application and not just simple examples then how do we get other to contribute to DPDK.org to build these applications without providing easy integration and building blocks for the developer?

> 
> 

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Jerin Jacob]

-----Original Message-----
> Date: Thu, 30 Mar 2017 15:11:07 +0530
> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> To: dev@dpdk.org
> Cc: techboard@dpdk.org
> Subject: [dpdk-dev] next technical board meeting, 2017-04-06
> User-Agent: NeoMutt/20170306 (1.8.0)
> 
> Hello everyone,
> 
> A meeting of the DPDK technical board will occur next Thursday,
> April 6th 2017 at 9am UTC?
> 
> The meeting takes place on the #dpdk-board channel on IRC.
> This meeting is public, so anybody can join, see below for the agenda.
> 
> Jerin

The meeting got canceled due to lack of quorum.
(6 out of 9 members were present, which is less than 70%(minimum quorum))
# http://dpdk.org/about/techboard#meetings

Yuanhan Liu volunteered to chair the next meeting.
No particular date was agreed for next meeting.

Yuanhan to follow on mail to select a date/time of next meeting.

> 
> 1) Divergence between DPDK/Linux PF/VF implementations.
> 
> Discussions:
> http://dpdk.org/ml/archives/dev/2017-March/060529.html
> http://dpdk.org/ml/archives/dev/2017-March/060063.html
> http://dpdk.org/ml/archives/dev/2016-December/053056.html
> 
> 2) Representative for the DPDK governance board
> 
> 3) Scope of cmdline and cfgfile libraries in DPDK.
> Discuss the scope of cmdline and cfgfile libraries in DPDK
> and see if we allow more libs like that (Keith proposed a CLI lib),
> or we do not do more,
> or do we target to replace them by better external equivalents?
> 
> 4) Community questions/issues
> 
> 
> 

[dpdk-dev] next technical board meeting, 2017-04-10

[Yuanhan Liu]

Hi all,

The last techboard meeting was canceled, and it's been rescheduled to
today, 10th Apr, at 3pm UTC. I should have sent it out a bit earlier.
Sorry!

The agenda remains the same (see below).

	--yliu

On Thu, Apr 06, 2017 at 03:31:43PM +0530, Jerin Jacob wrote:
> -----Original Message-----
> > Date: Thu, 30 Mar 2017 15:11:07 +0530
> > From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > To: dev@dpdk.org
> > Cc: techboard@dpdk.org
> > Subject: [dpdk-dev] next technical board meeting, 2017-04-06
> > User-Agent: NeoMutt/20170306 (1.8.0)
> > 
> > Hello everyone,
> > 
> > A meeting of the DPDK technical board will occur next Thursday,
> > April 6th 2017 at 9am UTC?
> > 
> > The meeting takes place on the #dpdk-board channel on IRC.
> > This meeting is public, so anybody can join, see below for the agenda.
> > 
> > Jerin
> 
> The meeting got canceled due to lack of quorum.
> (6 out of 9 members were present, which is less than 70%(minimum quorum))
> # http://dpdk.org/about/techboard#meetings
> 
> Yuanhan Liu volunteered to chair the next meeting.
> No particular date was agreed for next meeting.
> 
> Yuanhan to follow on mail to select a date/time of next meeting.
> 
> > 
> > 1) Divergence between DPDK/Linux PF/VF implementations.
> > 
> > Discussions:
> > http://dpdk.org/ml/archives/dev/2017-March/060529.html
> > http://dpdk.org/ml/archives/dev/2017-March/060063.html
> > http://dpdk.org/ml/archives/dev/2016-December/053056.html
> > 
> > 2) Representative for the DPDK governance board
> > 
> > 3) Scope of cmdline and cfgfile libraries in DPDK.
> > Discuss the scope of cmdline and cfgfile libraries in DPDK
> > and see if we allow more libs like that (Keith proposed a CLI lib),
> > or we do not do more,
> > or do we target to replace them by better external equivalents?
> > 
> > 4) Community questions/issues
> > 
> > 
> > 

Re: [dpdk-dev] next technical board meeting, 2017-04-10

[Wiles, Keith]

Did this meeting take place and meet quorum?

What is the out come of the meeting?

> On Apr 10, 2017, at 1:49 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com> wrote:
> 
> Hi all,
> 
> The last techboard meeting was canceled, and it's been rescheduled to
> today, 10th Apr, at 3pm UTC. I should have sent it out a bit earlier.
> Sorry!
> 
> The agenda remains the same (see below).
> 
> 	--yliu
> 
> On Thu, Apr 06, 2017 at 03:31:43PM +0530, Jerin Jacob wrote:
>> -----Original Message-----
>>> Date: Thu, 30 Mar 2017 15:11:07 +0530
>>> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>> To: dev@dpdk.org
>>> Cc: techboard@dpdk.org
>>> Subject: [dpdk-dev] next technical board meeting, 2017-04-06
>>> User-Agent: NeoMutt/20170306 (1.8.0)
>>> 
>>> Hello everyone,
>>> 
>>> A meeting of the DPDK technical board will occur next Thursday,
>>> April 6th 2017 at 9am UTC?
>>> 
>>> The meeting takes place on the #dpdk-board channel on IRC.
>>> This meeting is public, so anybody can join, see below for the agenda.
>>> 
>>> Jerin
>> 
>> The meeting got canceled due to lack of quorum.
>> (6 out of 9 members were present, which is less than 70%(minimum quorum))
>> # http://dpdk.org/about/techboard#meetings
>> 
>> Yuanhan Liu volunteered to chair the next meeting.
>> No particular date was agreed for next meeting.
>> 
>> Yuanhan to follow on mail to select a date/time of next meeting.
>> 
>>> 
>>> 1) Divergence between DPDK/Linux PF/VF implementations.
>>> 
>>> Discussions:
>>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
>>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
>>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
>>> 
>>> 2) Representative for the DPDK governance board
>>> 
>>> 3) Scope of cmdline and cfgfile libraries in DPDK.
>>> Discuss the scope of cmdline and cfgfile libraries in DPDK
>>> and see if we allow more libs like that (Keith proposed a CLI lib),
>>> or we do not do more,
>>> or do we target to replace them by better external equivalents?
>>> 
>>> 4) Community questions/issues
>>> 
>>> 
>>> 

Regards,
Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-10

[Dumitrescu, Cristian]

It will start in 15 mins.

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> Sent: Monday, April 10, 2017 3:34 PM
> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> Cc: dev@dpdk.org; techboard@dpdk.org; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>
> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-10
> 
> Did this meeting take place and meet quorum?
> 
> What is the out come of the meeting?
> 
> > On Apr 10, 2017, at 1:49 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
> wrote:
> >
> > Hi all,
> >
> > The last techboard meeting was canceled, and it's been rescheduled to
> > today, 10th Apr, at 3pm UTC. I should have sent it out a bit earlier.
> > Sorry!
> >
> > The agenda remains the same (see below).
> >
> > 	--yliu
> >
> > On Thu, Apr 06, 2017 at 03:31:43PM +0530, Jerin Jacob wrote:
> >> -----Original Message-----
> >>> Date: Thu, 30 Mar 2017 15:11:07 +0530
> >>> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >>> To: dev@dpdk.org
> >>> Cc: techboard@dpdk.org
> >>> Subject: [dpdk-dev] next technical board meeting, 2017-04-06
> >>> User-Agent: NeoMutt/20170306 (1.8.0)
> >>>
> >>> Hello everyone,
> >>>
> >>> A meeting of the DPDK technical board will occur next Thursday,
> >>> April 6th 2017 at 9am UTC?
> >>>
> >>> The meeting takes place on the #dpdk-board channel on IRC.
> >>> This meeting is public, so anybody can join, see below for the agenda.
> >>>
> >>> Jerin
> >>
> >> The meeting got canceled due to lack of quorum.
> >> (6 out of 9 members were present, which is less than 70%(minimum
> quorum))
> >> # http://dpdk.org/about/techboard#meetings
> >>
> >> Yuanhan Liu volunteered to chair the next meeting.
> >> No particular date was agreed for next meeting.
> >>
> >> Yuanhan to follow on mail to select a date/time of next meeting.
> >>
> >>>
> >>> 1) Divergence between DPDK/Linux PF/VF implementations.
> >>>
> >>> Discussions:
> >>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
> >>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
> >>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
> >>>
> >>> 2) Representative for the DPDK governance board
> >>>
> >>> 3) Scope of cmdline and cfgfile libraries in DPDK.
> >>> Discuss the scope of cmdline and cfgfile libraries in DPDK
> >>> and see if we allow more libs like that (Keith proposed a CLI lib),
> >>> or we do not do more,
> >>> or do we target to replace them by better external equivalents?
> >>>
> >>> 4) Community questions/issues
> >>>
> >>>
> >>>
> 
> Regards,
> Keith

Re: [dpdk-dev] next technical board meeting, 2017-04-10

[Wiles, Keith]

> On Apr 10, 2017, at 9:43 AM, Dumitrescu, Cristian <cristian.dumitrescu@intel.com> wrote:
> 
> It will start in 15 mins.

I assumed it was in the am like last time.

> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
>> Sent: Monday, April 10, 2017 3:34 PM
>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>> Cc: dev@dpdk.org; techboard@dpdk.org; Jerin Jacob
>> <jerin.jacob@caviumnetworks.com>
>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-10
>> 
>> Did this meeting take place and meet quorum?
>> 
>> What is the out come of the meeting?
>> 
>>> On Apr 10, 2017, at 1:49 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> The last techboard meeting was canceled, and it's been rescheduled to
>>> today, 10th Apr, at 3pm UTC. I should have sent it out a bit earlier.
>>> Sorry!
>>> 
>>> The agenda remains the same (see below).
>>> 
>>> 	--yliu
>>> 
>>> On Thu, Apr 06, 2017 at 03:31:43PM +0530, Jerin Jacob wrote:
>>>> -----Original Message-----
>>>>> Date: Thu, 30 Mar 2017 15:11:07 +0530
>>>>> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>>> To: dev@dpdk.org
>>>>> Cc: techboard@dpdk.org
>>>>> Subject: [dpdk-dev] next technical board meeting, 2017-04-06
>>>>> User-Agent: NeoMutt/20170306 (1.8.0)
>>>>> 
>>>>> Hello everyone,
>>>>> 
>>>>> A meeting of the DPDK technical board will occur next Thursday,
>>>>> April 6th 2017 at 9am UTC?
>>>>> 
>>>>> The meeting takes place on the #dpdk-board channel on IRC.
>>>>> This meeting is public, so anybody can join, see below for the agenda.
>>>>> 
>>>>> Jerin
>>>> 
>>>> The meeting got canceled due to lack of quorum.
>>>> (6 out of 9 members were present, which is less than 70%(minimum
>> quorum))
>>>> # http://dpdk.org/about/techboard#meetings
>>>> 
>>>> Yuanhan Liu volunteered to chair the next meeting.
>>>> No particular date was agreed for next meeting.
>>>> 
>>>> Yuanhan to follow on mail to select a date/time of next meeting.
>>>> 
>>>>> 
>>>>> 1) Divergence between DPDK/Linux PF/VF implementations.
>>>>> 
>>>>> Discussions:
>>>>> http://dpdk.org/ml/archives/dev/2017-March/060529.html
>>>>> http://dpdk.org/ml/archives/dev/2017-March/060063.html
>>>>> http://dpdk.org/ml/archives/dev/2016-December/053056.html
>>>>> 
>>>>> 2) Representative for the DPDK governance board
>>>>> 
>>>>> 3) Scope of cmdline and cfgfile libraries in DPDK.
>>>>> Discuss the scope of cmdline and cfgfile libraries in DPDK
>>>>> and see if we allow more libs like that (Keith proposed a CLI lib),
>>>>> or we do not do more,
>>>>> or do we target to replace them by better external equivalents?
>>>>> 
>>>>> 4) Community questions/issues
>>>>> 
>>>>> 
>>>>> 
>> 
>> Regards,
>> Keith
> 

Regards,
Keith