From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by dpdk.org (Postfix) with ESMTP id 233D9326C for ; Tue, 4 Apr 2017 07:01:52 +0200 (CEST) Received: by mail-wr0-f178.google.com with SMTP id k6so192163036wre.2 for ; Mon, 03 Apr 2017 22:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:date:message-id:in-reply-to:references:user-agent :subject:mime-version:content-transfer-encoding; bh=cDFvAkazNNW4A0Mf/ZvrjCYiLrIC+OzznXEljPwrPao=; b=Cy8wkaXOuRVid60eswIaE6qQSvp4iUbvlr4fTo5tCCT1yiLVACXANdR93w3Q3Pph4l yEomhVzTunkhcWLuAI8pD8GfMVtOorwNB+RR4S/pV7HLSbw77OiOLTfWBnK7fQJgaemy 1YUERaZu25eMOwMrSe0nelJAKHhl4CZKiJdNl5EVaP1nphFzc/kKwM5Q6SkT6VzsT+SM nfURqLGQLdimQ35gX8pXE2PjvOUVhWN8XX5at3L8n+HzlbBM/r4v+QTxNvO2Mba/XSZW ZXCrGf1olsvOqKjN53ep0rPZ9SCl3kSyGVy4pKXKtMXj8gY9VcsKvuzlLOECiR7aYuTJ dicA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to :references:user-agent:subject:mime-version :content-transfer-encoding; bh=cDFvAkazNNW4A0Mf/ZvrjCYiLrIC+OzznXEljPwrPao=; b=Rw4iotuesEnVcos2miCBgbSBd+Iha1utN2nRawz3pFtdGNX3KSq93/Zx+/CssdzfDY c7N0W5wVueG1OmEV/w4y2SgV7Tb3VYPkBWq+c9uZuOpYJPrQjylfea7rj89+KASHMaF/ CTaTbfBShgYCFAutHmiUE/ADoDlAOTBR5rXQN4VVIqbC2ZXZG4AIFOSqZ6n55EFJ1csM yt4s43Ldwv4kuJRs/P52EIwwF2gCC0mosfzgpFK/Q0egWWIPdlXXa65HQyTT0Qqn/VUP XfJlwwNrPGnjqmkFk99a8Zs4yCHUSgslnF0Uo83UJTl0xu7rh+w5w22lNyl19+x/qGJA dhLQ== X-Gm-Message-State: AFeK/H1Er2ww1/hkydYfjVdINOfR8EGfed+CHctfrP21bfYq1u5EGFnbi1EUlqs33CHECtv8 X-Received: by 10.223.168.120 with SMTP id l111mr18933440wrc.173.1491282111730; Mon, 03 Apr 2017 22:01:51 -0700 (PDT) Received: from [172.20.10.2] ([37.164.246.218]) by smtp.gmail.com with ESMTPSA id a18sm20690631wrc.58.2017.04.03.22.01.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 22:01:50 -0700 (PDT) From: Vincent Jardin To: Stephen Hemminger , "Wiles, Keith" CC: "Dumitrescu, Cristian" , Jay Rolette , Olivier Matz , Jerin Jacob , , Date: Tue, 04 Apr 2017 08:01:47 +0300 Message-ID: <15b37571a78.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: <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> <20170403182836.45f97c61@plumbers-lap.home.lan> User-Agent: AquaMail/1.8.2-216 (build: 100800200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] next technical board meeting, 2017-04-06 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 05:01:52 -0000 Le 4 avril 2017 4:28:47 AM Stephen Hemminger a écrit : > On Mon, 3 Apr 2017 22:53:06 +0000 > "Wiles, Keith" wrote: > >> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger >> wrote: >> > >> > On Thu, 30 Mar 2017 18:09:04 +0000 >> > "Dumitrescu, Cristian" wrote: >> > >> >>> -----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 >> >>> >> >>> On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith >> >>> wrote: >> >>> >> >>> >> >>>> >> >>>> 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. >> >> Stephen, >> >> 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. >> >> Regards, >> Keith >> > > 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).