From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 89340CF68; Thu, 30 Mar 2017 16:25:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490883916; x=1522419916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZPp0nWzfWPE2g1EJXvnaQVQgJGzbwc70Hx2RL8+9ywM=; b=clxkn1FW4Kizr8BAEKkatudcatacrbHXc6bzC0z2REFQnmAXi97NnaNm e7ODhDX1HzHfcHyYJW7xolycqTR76g==; Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 07:25:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,246,1486454400"; d="scan'208";a="1113665310" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 30 Mar 2017 07:25:14 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 30 Mar 2017 07:25:13 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.235]) by FMSMSX155.amr.corp.intel.com ([169.254.5.24]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 07:25:13 -0700 From: "Wiles, Keith" To: Jerin Jacob CC: "dev@dpdk.org" , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] next technical board meeting, 2017-04-06 Thread-Index: AQHSqULYuut+hGV6VUGL8EwZviB91qGt5bUA Date: Thu, 30 Mar 2017 14:25:12 +0000 Message-ID: References: <20170330094058.nh2nhk4ko6tsqedn@localhost.localdomain> In-Reply-To: <20170330094058.nh2nhk4ko6tsqedn@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.88.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 30 Mar 2017 14:25:17 -0000 > 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? I would prefer not lumping cfgfile into the CLI discussion, we can have a d= ifferent discussion on it later. A couple of options for CLI are: 1 - Include CLI in DPDK repo, then start converting apps to CLI. Keep or deprecate cmdline in the future. 2 - Include CLI in DPDK repo, do not convert current APPs allow new apps t= o use cmdline or CLI. 3 - Put CLI in a different repo in DPDK, do not convert apps to use CLI al= low developers to decide if they want to use CLI. - I would like to be able to clone CLI into DPDK lib directory and bui= ld it as a DPDK library. This would mean updating common_base, lib/Makefile and rte.apps.mk u= sing a patch or use common_base config option. Building CLI outside of DPDK as a external lib is not very easy for = developers to manage. Could use a patch to include CLI into the DPDK build system, but jus= t adding the configuration defaulted off is the cleaner way. We talked about creating a new repo on DPDK.org and I am happy with it, jus= t want it better integrated into DPDK as a first class library to make usin= g it simpler and easier for developers. Doing option #1 or #2 is my first choice, but option #3 is good if we can h= ave it as a first class library. >=20 > 4) Community questions/issues >=20 >=20 >=20 Regards, Keith