From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B8F2169C5 for ; Tue, 28 Mar 2017 11:58:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490695098; x=1522231098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=br57WZg/yX5q2+jAXaokgDIAmiSmIPT6DAxeobuT1So=; b=RGAHtZyz5NEhKA+ZAWyPei9bZnKErFARwpXo6S4ckngojSiisseJZQJF e1fkYCRgm+6yHud3aPPVeEmDMTnC4A==; Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 02:58:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,236,1486454400"; d="scan'208";a="1127975376" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga001.fm.intel.com with ESMTP; 28 Mar 2017 02:58:16 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX107.ger.corp.intel.com (163.33.3.99) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Mar 2017 10:58:12 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.239]) by IRSMSX156.ger.corp.intel.com ([169.254.3.246]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 10:58:12 +0100 From: "Dumitrescu, Cristian" To: Thomas Monjalon , "Richardson, Bruce" CC: "Legacy, Allain (Wind River)" , "dev@dpdk.org" , "yuanhan.liu@linux.intel.com" Thread-Topic: [dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements Thread-Index: AQHSmNarI1I75TdkvkC/5qQNqNb7E6Gp+HYAgAANngCAAAEpgIAABUYAgAATb3A= Date: Tue, 28 Mar 2017 09:58:11 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891265277FF85@IRSMSX108.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <20170328091828.GA16008@bricha3-MOBL3.ger.corp.intel.com> <20170328092237.GB16008@bricha3-MOBL3.ger.corp.intel.com> <22590962.V8IQgtpKlO@xps13> In-Reply-To: <22590962.V8IQgtpKlO@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTcxY2VhYTEtOTI1OS00YzgzLTk4MDMtYzA2ZTQ2NzU4NDc2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImNMWHk0ZHhOQW8rNlpwbHFEQ2d2dWUyNHlncEdwb2w4OWVuQjVncmJTcEE9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements 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, 28 Mar 2017 09:58:19 -0000 > > As follow-up to my own mail, for this specific library example, I > > wouldn't look to remove it from DPDK anyway. Parsing ini files is fairl= y > > trivial, so I think it's not a big deal to keep our own version and not > > have an external dependency - especially since it's already there and n= ot > > a big maintenance burden. >=20 > Removing this lib would not disable anything as it is used only by exampl= es. > I don't see what would be the issue. > We just have to download the lib when building the example app. > It can be done quite easily in the makefile. >=20 Thomas, more than 3 quarters of DPDK libs are only used by applications, is= this a reason to remove them? Also, I think the purpose of DPDK is to enable people to write applications= , not more libraries. Would you agree? We should make the life easier for t= he application developers, not libraries. This library is an important utility for applications, similar to librte_cm= dline and others. I think it is not fair from your side to refer to librte_= cfgfile without any reference to librte_cmdline. > > For newer functionalty, we do need clear guidelines as to when it is > > acceptable to add new dependencies to DPDK. I'd love to see us enable > > the PCAP PMD by default, for instance, and I think Sergio has recently > > proposed we also require libnuma on Linux. >=20 > We won't include libpcap or libnuma. > The only thing we should do is to make easier to view and enable > dependencies.