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

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

> 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