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

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

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