From: Vincent Jardin <email@example.com>
To: Stephen Hemminger <firstname.lastname@example.org>,
"Wiles, Keith" <email@example.com>
Cc: "Dumitrescu, Cristian" <firstname.lastname@example.org>,
Jay Rolette <email@example.com>,
Olivier Matz <firstname.lastname@example.org>,
Jerin Jacob <email@example.com>, <firstname.lastname@example.org>,
Subject: Re: next technical board meeting, 2017-04-06
Date: Tue, 04 Apr 2017 08:01:47 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
Le 4 avril 2017 4:28:47 AM Stephen Hemminger <firstname.lastname@example.org> a
> On Mon, 3 Apr 2017 22:53:06 +0000
> "Wiles, Keith" <email@example.com> wrote:
>> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger
>> <firstname.lastname@example.org> wrote:
>> > On Thu, 30 Mar 2017 18:09:04 +0000
>> > "Dumitrescu, Cristian" <email@example.com> wrote:
>> >>> -----Original Message-----
>> >>> From: dev [mailto:firstname.lastname@example.org] On Behalf Of Jay Rolette
>> >>> Sent: Thursday, March 30, 2017 5:03 PM
>> >>> To: Wiles, Keith <email@example.com>
>> >>> Cc: Olivier Matz <firstname.lastname@example.org>; Jerin Jacob
>> >>> <email@example.com>; firstname.lastname@example.org; email@example.com
>> >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
>> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <firstname.lastname@example.org>
>> >>> wrote:
>> >>> <snip>
>> >>>> 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,
>> >>>> Keith
>> >>> Yes!
>> >> +1
>> > Yes but it needs some architecture. Sorry but the features flying in are
>> > just addressing single use cases and have no unifying model.
>> Not sure I fully understand your comment here. I was only adding features
>> here, the architecture would be a much longer doc. I was working more on
>> the docs this weekend, but did not make a lot of progress (I am not the
>> best doc writer in the world). Posting the cli.rst file to the list I am
>> sure would be frowned on, but I did include them in the Pktgen version of
>> the code.
>> I would be great if you could explain your views on a architecture for a CLI.
>> To me a CLI should provide a clean and easy way to add commands for the
>> developer, but at the same time provide simple ways to execute these
>> commands. Now creating a user level design to make it easy for the user to
>> navigate or use the commands that one is very broad as everyone has his own
>> ideas on what is simple and easy to use.
>> Some CLIs attempt to provide a very strict user level model and it may make
>> the developer user model easier. My goal was to give a similar user level
>> model to CLI as cmdline, but provide a much easier developer level model.
>> Some CLIs attempt to provide the most generic solution to create any type
>> of user level model, these are normally very complex and difficult for the
>> developer to use. The developer in these cases have to create that user
>> level model, which we all know can be very ugly for the user. The cmdline
>> attempts to handle all of the conversion of the types and provides a strict
>> developer model. The commands are strict in the sense they are not flexible
>> by allowing for different number of arguments/type to the same basic
>> command. We have added things like kvargs and I have added to Pktgen a
>> argc/argv method. These then require the developer to decode the argv
>> strings. The cmdline design I was always looking for ways to work around
>> the developer model as it was difficult to use with complex command, so in
>> CLI I removed that restriction for the better I think.
>> CLI provides a directory like command layout with directories, command,
>> files and alias commands. The user level model is very similar to cmdline,
>> but the developer model is very simple and very fast to add a new command
>> and complex commands as well.
>> Using CLI you can make it look like cmdline from the user view point or you
>> can use the directory structure. I find it easier to group commands and
>> function in directories, but YMMV.
> My concern is that DPDK is growing because of lots of contributions (good)
> but that
> each contribution only thinks of their own narrow use case. This is because
> as it says on the
> web page, DPDK is not a complete product. VPP (and others) are a more of a
> product and each
> feature is more integrated. Think of Gnome and KDE, they strive to provide
> a complete
> desktop experience and each application is part of that. DPDK does not have
> a really
> strong over arching vision and mission which new contributions can be
> judged against.
> Maybe a better example is some of the language class libraries. They
> provide broad set
> of tools but the all play well together. Right now DPDK is not consistent.
> It is possible
> to build something complex like a NAT IPv6 load balancer and firewall with
> QoS. But
> it is not obvious, complete or easy.
> So my concerns are not about the CLI. It is just that CLI is just an
> example of an individual function that stands alone. Having more tools is
> good, but if they don't
> fit together easily, then more tools doesn't help.
The goal is beyond DPDK : we need a wide set of community building
applications (VPP vs OVS-DPDK vs Lagopus vs xyz).
next prev parent reply other threads:[~2017-04-04 5:01 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
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 [this message]
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.