From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AD33BA04A2; Wed, 6 Nov 2019 10:38:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 36F172BE5; Wed, 6 Nov 2019 10:38:49 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id BC3462B9E for <dev@dpdk.org>; Wed, 6 Nov 2019 10:38:47 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 01:38:46 -0800 X-IronPort-AV: E=Sophos;i="5.68,274,1569308400"; d="scan'208";a="196144652" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2019 01:38:44 -0800 Date: Wed, 6 Nov 2019 09:38:41 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: Stephen Hemminger <stephen@networkplumber.org>, Gagandeep Singh <g.singh@nxp.com>, dev@dpdk.org, thomas@monjalon.net, Akhil Goyal <akhil.goyal@nxp.com> Message-ID: <20191106093841.GA1379@bricha3-MOBL.ger.corp.intel.com> References: <20190826130246.30485-1-g.singh@nxp.com> <20190826130246.30485-3-g.singh@nxp.com> <20191028101843.3a5b65ea@hermes.lan> <d85d7238-0333-ad88-a8a8-b3f52a94530b@intel.com> <20191104110620.GB1356@bricha3-MOBL.ger.corp.intel.com> <29b83404-2ec3-8992-26b1-20f9ff609603@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29b83404-2ec3-8992-26b1-20f9ff609603@intel.com> User-Agent: Mutt/1.12.1 (2019-06-15) Subject: Re: [dpdk-dev] [PATCH v1 02/13] net/ppfe: introduce ppfe net poll mode driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Tue, Nov 05, 2019 at 04:02:52PM +0000, Ferruh Yigit wrote: > On 11/4/2019 11:06 AM, Bruce Richardson wrote: > > On Tue, Oct 29, 2019 at 09:27:22AM +0000, Ferruh Yigit wrote: > >> On 10/28/2019 5:18 PM, Stephen Hemminger wrote: > >>> On Mon, 26 Aug 2019 18:32:35 +0530 > >>> Gagandeep Singh <g.singh@nxp.com> wrote: > >>> > >>>> --- a/config/common_base > >>>> +++ b/config/common_base > >>>> @@ -224,6 +224,11 @@ CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n > >>>> CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n > >>>> CONFIG_RTE_LIBRTE_CXGBE_TPUT=y > >>>> > >>>> +# > >>>> +# Compile burst-oriented NXP PPFE PMD driver > >>>> +# > >>>> +CONFIG_RTE_LIBRTE_PPFE_PMD=n > >>> > >>> This driver should use the common naming convention for Poll Mode Drivers. > >>> > >>> s/CONFIG_RTE_LIBRTE_PPFE_PMD/CONFIG_RTE_LIBRTE_PMD_PPFE/ > >>> > >> > >> Unfortunately we have both as naming convention, and *unintentionally* it become > >> virtual ones PMD_XXXX (PMD_RING), physical ones (IXGBE_PMD), > >> although this PMD registers itself as virtual, it is a physical PMD and I think > >> exiting config option is good (PPFE_PMD). > >> > >> We can update config names to be consistent but not sure if it worth it, > >> changing name for users/costumers which may break their scripts, automation etc. > >> taking into account that it was like this since beginning, > >> > >> And now we are planning to switch to meson, these config option won't be used > >> directly, so I think we can keep them as they are. > > > > ... and the meson default is PMD at the end as for physical PMDs. > > > > Does meson need them? > I was thinking these PMD build enable/disable configs will go away with meson. They are not needed for meson, but they are needed for some C code so that applications or other drivers can have #ifdefs based on the presence of some other driver. Therefore, for each library or driver which will be built we add the appropriate RTE_LIBRTE_... #define to the config.h file. /Bruce