From: Olivier Matz <firstname.lastname@example.org>
To: "Wiles, Keith" <email@example.com>
Cc: Jerin Jacob <firstname.lastname@example.org>,
Subject: Re: next technical board meeting, 2017-04-06
Date: Thu, 30 Mar 2017 17:05:12 +0200 [thread overview]
Message-ID: <20170330170512.14476bb0@platinum> (raw)
On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" <email@example.com> wrote:
> > On Mar 30, 2017, at 4:41 AM, Jerin Jacob <firstname.lastname@example.org> 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
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
> 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?
next prev parent reply other threads:[~2017-03-30 15:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 9:41 next technical board meeting, 2017-04-06 Jerin Jacob
2017-03-30 14:25 ` Wiles, Keith
2017-03-30 15:05 ` Olivier Matz [this message]
2017-03-30 15:51 ` Wiles, Keith
2017-03-30 16:03 ` Jay Rolette
2017-03-30 18:09 ` Dumitrescu, Cristian
2017-04-03 19:51 ` Stephen Hemminger
2017-04-03 22:53 ` Wiles, Keith
2017-04-04 1:28 ` Stephen Hemminger
2017-04-04 5:01 ` Vincent Jardin
2017-04-04 14:35 ` Wiles, Keith
2017-03-31 8:52 ` Olivier Matz
2017-03-31 9:31 ` Dumitrescu, Cristian
2017-03-31 14:24 ` Wiles, Keith
2017-03-31 14:39 ` Wiles, Keith
2017-04-06 10:01 ` Jerin Jacob
2017-04-10 6:49 ` next technical board meeting, 2017-04-10 Yuanhan Liu
2017-04-10 14:34 ` Wiles, Keith
2017-04-10 14:43 ` Dumitrescu, Cristian
2017-04-10 14:54 ` Wiles, Keith
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.