Re: [dpdk-dev] next technical board meeting, 2017-04-06

[Vincent Jardin <vincent.jardin@6wind.com>]

Le 4 avril 2017 4:28:47 AM Stephen Hemminger <stephen@networkplumber.org> a 
écrit :

> On Mon, 3 Apr 2017 22:53:06 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>> > On Apr 3, 2017, at 2:51 PM, Stephen Hemminger 
>> <stephen@networkplumber.org> wrote:
>> >
>> > On Thu, 30 Mar 2017 18:09:04 +0000
>> > "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> 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 <keith.wiles@intel.com>
>> >>> Cc: Olivier Matz <olivier.matz@6wind.com>; Jerin Jacob
>> >>> <jerin.jacob@caviumnetworks.com>; 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 <keith.wiles@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.
>>
>> 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).