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

[Wiles, Keith]

> On Mar 31, 2017, at 3:52 AM, Olivier Matz <olivier.matz at 6wind.com> wrote:
> 
> Hi,
> 
> On Thu, 30 Mar 2017 15:51:48 +0000, "Wiles, Keith" <keith.wiles at intel.com> wrote:
>>> On Mar 30, 2017, at 10:05 AM, Olivier Matz <olivier.matz at 6wind.com> wrote:
>>> 
>>> Hi Keith,
>>> 
>>> On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <keith.wiles at intel.com> wrote:  
>>>>> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.jacob at 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