> On Mar 30, 2017, at 4:41 AM, Jerin Jacob <jerin.ja...@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
