[dpdk-dev] next technical board meeting, 2017-04-06
vincent.jardin at 6wind.com
Tue Apr 4 07:01:47 CEST 2017
Le 4 avril 2017 4:28:47 AM Stephen Hemminger <stephen at networkplumber.org> a
> On Mon, 3 Apr 2017 22:53:06 +0000
> "Wiles, Keith" <keith.wiles at intel.com> wrote:
>> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger
>> <stephen at networkplumber.org> wrote:
>> > On Thu, 30 Mar 2017 18:09:04 +0000
>> > "Dumitrescu, Cristian" <cristian.dumitrescu at intel.com> wrote:
>> >>> -----Original Message-----
>> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
>> >>> Sent: Thursday, March 30, 2017 5:03 PM
>> >>> To: Wiles, Keith <keith.wiles at intel.com>
>> >>> Cc: Olivier Matz <olivier.matz at 6wind.com>; Jerin Jacob
>> >>> <jerin.jacob at caviumnetworks.com>; dev at dpdk.org; techboard at dpdk.org
>> >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06
>> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith <keith.wiles at intel.com>
>> >>> 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).
More information about the dev