Re: next technical board meeting, 2017-04-06

["Wiles, Keith" <keith.wiles@intel.com>]

> 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