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

[Olivier Matz <olivier.matz@6wind.com>]

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