From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: next technical board meeting, 2017-04-06 Date: Mon, 3 Apr 2017 18:28:36 -0700 Message-ID: <20170403182836.45f97c61@plumbers-lap.home.lan> References: <20170330094058.nh2nhk4ko6tsqedn@localhost.localdomain> <20170330170512.14476bb0@platinum> <5C76150C-195D-4316-AC3B-6AE2441B254B@intel.com> <3EB4FA525960D640B5BDFFD6A3D89126527834A9@IRSMSX108.ger.corp.intel.com> <20170403125107.2c23bfc0@plumbers-lap.home.lan> <910B9051-85F8-4461-8A29-30B9D803BA33@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Dumitrescu, Cristian" , Jay Rolette , Olivier Matz , Jerin Jacob , "dev@dpdk.org" , "techboard@dpdk.org" To: "Wiles, Keith" Return-path: Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by dpdk.org (Postfix) with ESMTP id D09F53005 for ; Tue, 4 Apr 2017 03:28:42 +0200 (CEST) Received: by mail-pg0-f50.google.com with SMTP id x125so136678977pgb.0 for ; Mon, 03 Apr 2017 18:28:42 -0700 (PDT) In-Reply-To: <910B9051-85F8-4461-8A29-30B9D803BA33@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 3 Apr 2017 22:53:06 +0000 "Wiles, Keith" wrote: > > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger wrote: > >=20 > > On Thu, 30 Mar 2017 18:09:04 +0000 > > "Dumitrescu, Cristian" wrote: > > =20 > >>> -----Original Message----- > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette > >>> Sent: Thursday, March 30, 2017 5:03 PM > >>> To: Wiles, Keith > >>> Cc: Olivier Matz ; Jerin Jacob > >>> ; dev@dpdk.org; techboard@dpdk.org > >>> Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06 > >>>=20 > >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith > >>> wrote: > >>>=20 > >>> =20 > >>>>=20 > >>>> My Soap box comment: > >>>> I think we are limiting DPDK=E2=80=99s growth by only focusing on = a few new > >>>> PMDs and reworking the existing code. We need to look forward and gr= ow =20 > >>> DPDK =20 > >>>> as a community to get more people involved in adding more applicatio= ns =20 > >>> and =20 > >>>> new designs. I believe DPDK.org needs to be a bigger community and n= ot =20 > >>> just =20 > >>>> 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, libr= aries > >>>> and features. > >>>>=20 > >>>> Regards, > >>>> Keith > >>>> =20 > >>>=20 > >>> Yes! =20 > >>=20 > >> +1 =20 > >=20 > > Yes but it needs some architecture. Sorry but the features flying in are > > just addressing single use cases and have no unifying model. =20 >=20 > Stephen, >=20 > 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 t= he 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 w= ould be frowned on, but I did include them in the Pktgen version of the cod= e. >=20 > I would be great if you could explain your views on a architecture for a = CLI. >=20 > To me a CLI should provide a clean and easy way to add commands for the d= eveloper, but at the same time provide simple ways to execute these command= s. Now creating a user level design to make it easy for the user to navigat= e or use the commands that one is very broad as everyone has his own ideas = on what is simple and easy to use. >=20 > Some CLIs attempt to provide a very strict user level model and it may ma= ke the developer user model easier. My goal was to give a similar user leve= l model to CLI as cmdline, but provide a much easier developer level model. >=20 > 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 le= vel model, which we all know can be very ugly for the user. The cmdline at= tempts to handle all of the conversion of the types and provides a strict d= eveloper model. The commands are strict in the sense they are not flexible = by allowing for different number of arguments/type to the same basic comman= d. 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 cm= dline design I was always looking for ways to work around the developer mod= el as it was difficult to use with complex command, so in CLI I removed tha= t restriction for the better I think. >=20 > CLI provides a directory like command layout with directories, command, f= iles and alias commands. The user level model is very similar to cmdline, b= ut the developer model is very simple and very fast to add a new command an= d complex commands as well. >=20 > Using CLI you can make it look like cmdline from the user view point or y= ou can use the directory structure. I find it easier to group commands and = function in directories, but YMMV. >=20 > Regards, > Keith >=20 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 judge= d against. Maybe a better example is some of the language class libraries. They provid= e 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 exampl= e of an individual function that stands alone. Having more tools is good, b= ut if they don't fit together easily, then more tools doesn't help.