From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id BFB402B93 for ; Fri, 31 Mar 2017 10:52:32 +0200 (CEST) Received: by mail-wr0-f176.google.com with SMTP id k6so90340569wre.2 for ; Fri, 31 Mar 2017 01:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3L1dph/e21ggb+wsr6vQu+FmLc0+r6um4jg9ZVsXvJ4=; b=Nbfo8G+i5bjVWuK3R7LznqriCDL/tDFUNZPiX1TRoTjSdPzIppKR9HkJftmKcnhuAe IoJZenR2lOFgF//wyiHS6aZbRaGLoDV+HzPWcCKTN3jDq5x0f2/Q5QulGY/4F6nDxbn8 +qZ9N/b73zihmSm3jYSezAQYBRwNF/T1Mykd7MIqo9R5ANsYBu/CnKUUKKi1r0HXl+qx 3MsiN4/p86qxfM/qLvDZfMwKgelNhuAMsnZfqEv5ltlRm1LhtvbyjWLDUFl8Yp1YZYrL WLe0a4Rbvtfwq0QIwrv8F4YA2aq0XyK3qEExTnCtDdp3+LiO2oqeKuhhYhwEUfAZpjHI W14A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3L1dph/e21ggb+wsr6vQu+FmLc0+r6um4jg9ZVsXvJ4=; b=DwZacmt+o7HVxTA7BfhNSSC/q/FrHIx773DuWR+dlWsvzJZtjrUdMzo3MXI4Xxy77y AGWSM+y7HCJThPTzwzu7fyV/QOB2XyQ/704moWvQt3eLoITz98cgY0Nlyc2n5deh8Klb bYjiW65N4FivI5+kKNFgrhW5jWY+l3dN/7cZKUVcsdZU9dyiPvplR6YDj15MdPHPwH1d leIQCEgiBW66bSGSvuRIWsnzZ3d7BfXsCSaT9IHoZwUbBJhN+TqwYp08iK2GOm8jw8Gp OzzLIGrqYC9C13HrBtwLeF4n1P/6jKhp2LGcEmmkdxoyvWZgIlOGuVrHEL5i8mu0L2oL QByw== X-Gm-Message-State: AFeK/H0gjW00gzy5eMIV970cVs3oL5DzmmvIiBwZUWoIqoGtSJUEGJsK3dPK4CNGhDC/54m5 X-Received: by 10.28.157.150 with SMTP id g144mr1736260wme.89.1490950352045; Fri, 31 Mar 2017 01:52:32 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id q129sm5390719wmg.1.2017.03.31.01.52.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 31 Mar 2017 01:52:31 -0700 (PDT) Date: Fri, 31 Mar 2017 10:52:28 +0200 From: Olivier Matz To: "Wiles, Keith" Cc: Jerin Jacob , "dev@dpdk.org" , "techboard@dpdk.org" Message-ID: <20170331105228.36617583@platinum> In-Reply-To: <5C76150C-195D-4316-AC3B-6AE2441B254B@intel.com> References: <20170330094058.nh2nhk4ko6tsqedn@localhost.localdomain> <20170330170512.14476bb0@platinum> <5C76150C-195D-4316-AC3B-6AE2441B254B@intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 31 Mar 2017 08:52:33 -0000 Hi, On Thu, 30 Mar 2017 15:51:48 +0000, "Wiles, Keith" = wrote: > > On Mar 30, 2017, at 10:05 AM, Olivier Matz wro= te: > >=20 > > Hi Keith, > >=20 > > On Thu, 30 Mar 2017 14:25:12 +0000, "Wiles, Keith" wrote: =20 > >>> On Mar 30, 2017, at 4:41 AM, Jerin Jacob wrote: > >>>=20 > >>> Hello everyone, > >>>=20 > >>> A meeting of the DPDK technical board will occur next Thursday, > >>> April 6th 2017 at 9am UTC? > >>>=20 > >>> The meeting takes place on the #dpdk-board channel on IRC. > >>> This meeting is public, so anybody can join, see below for the agenda. > >>>=20 > >>> Jerin > >>>=20 > >>> 1) Divergence between DPDK/Linux PF/VF implementations. > >>>=20 > >>> Discussions: > >>> http://dpdk.org/ml/archives/dev/2017-March/060529.html > >>> http://dpdk.org/ml/archives/dev/2017-March/060063.html > >>> http://dpdk.org/ml/archives/dev/2016-December/053056.html > >>>=20 > >>> 2) Representative for the DPDK governance board > >>>=20 > >>> 3) Scope of cmdline and cfgfile libraries in DPDK. > >>> Discuss the scope of cmdline and cfgfile libraries in DPDK > >>> and see if we allow more libs like that (Keith proposed a CLI lib), > >>> or we do not do more, > >>> or do we target to replace them by better external equivalents? =20 > >>=20 > >> I would prefer not lumping cfgfile into the CLI discussion, we can hav= e a different discussion on it later. > >>=20 > >> A couple of options for CLI are: > >>=20 > >> 1 - Include CLI in DPDK repo, then start converting apps to CLI. > >> Keep or deprecate cmdline in the future. =20 > >=20 > > Before including the CLI lib and consider replacing the cmdline, > > we should first all be convinced that: > > - the app code will be more maintainable =20 >=20 > The app code for CLI IMO is far easier to maintain, but without others lo= oking at the code and working with the code in an application it will be di= fficult for others to comment on this design. I feel it is obvious that CLI= provides many new features and being dynamic at runtime then cmdline, but = others need to work with the code and convert or write an application. >=20 > CLI uses known methods (arg/argv) and again I was able to reduce test-pmd= from 12K lines to 4.5K lines of code, which I can provide a copy if someon= e wants to look at the conversion or just look at Pktgen. >=20 > As far as the CLI code I have tried to make it reasonable easy to maintai= n, but it can always be improved. That's exactly what I am requesting. If it appears that the testpmd code is smaller and clearer with the new cli lib, it's one good argument. > > - we will be able to replace all that we have (we won't loose feature) = =20 >=20 > I have attempted to keep most of the features in cmdline that I thought w= ere the key features, but what are the features of cmdline? Someone needs t= o present a fair comparison to CLI and cmdline. I think "someone" should be "you" ;) (with the help of community). If you're willing to replace librte_cmdline, you need to present in how librte_cli is better. [...] > >> We talked about creating a new repo on DPDK.org and I am happy with it= , just want it better integrated into DPDK as a first class library to make= using it simpler and easier for developers. > >>=20 > >> Doing option #1 or #2 is my first choice, but option #3 is good if we = can have it as a first class library. =20 > >=20 > > What does first class mean? =20 >=20 > First class means allowing CLI or other applications or libraries to be e= asily included into DPDK using the standard internal build system. >=20 > Take Pktgen it is one of the must used applications for DPDK today, but i= t has to be built outside of DPDK using DPDK external build support. The ex= ternal build support IMO could be dropped (less code to deal with) and just= allow someone to clone a repo into a DPDK directory enable the config and = build DPDK normally using the standard make options. This allows all applic= ations to locate the common includes and libraries without having to add co= de to the Makefile to locate includes and libraries as they are all contain= ed in the standard DPDK location. Here, you are just requesting to enhance the external build support, right? Well, why not. Although it would probably be better to let the application use its own Makefiles. For that, we need the DPDK to provide the proper infos (include path, lib path, ...), something like pkg-config. >=20 > We can add automatic support for new config files into the build system w= ithout having to edit DPDK files to make it build. >=20 >=20 > My Soap box comment: > I think we are limiting DPDK=E2=80=99s growth by only focusing on a fe= w new PMDs and reworking the existing code. We need to look forward and gro= w DPDK as a community to get more people involved in adding more applicatio= ns and new designs. I believe DPDK.org needs to be a bigger community and n= ot just a I/O library called DPDK. We need to actively move the organizatio= n to include more then just a high speed I/O library. Some will focus on DP= DK and others will focus on providing a higher level applications, librarie= s and features. Sorry, I completly disagree with that vision. I think the scope of dpdk should be more focused. Today, when someone adds a feature, (s)he sometimes updates eal, or mbuf, or any core layer required for its need. It can be just a hack, no matter if the feature works. I have many examples like this. This makes any rework/enhancement of core libs painful. Having separated core libs would encourage people to submit proper generic enhancements, to have stable APIs. Having more and more code in dpdk will confuse the new users. I'm also convinced it will decrease overall code quality. It will increase traffic on the mailing list. It goes against the principle of "keep it simple, small". You say you cannot find any good and public cli library. Putting it in the dpdk would solve your problem but would let the problem open for the rest of the world: "there is still no good and public cli library". If you put your lib in a separate rep, with no deps to dpdk, it will become usable for everyone... therefore it will bring more people willing to help you to enhance this library... enhancing dpdk indirectly. My 2 cents, Olivier