From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4B4ECA046B for ; Fri, 28 Jun 2019 14:40:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4ABAD3798; Fri, 28 Jun 2019 14:40:42 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 142E534F0 for ; Fri, 28 Jun 2019 14:40:40 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 05:40:40 -0700 X-IronPort-AV: E=Sophos;i="5.63,427,1557212400"; d="scan'208";a="153361117" Received: from vyashin-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.21.39]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 05:40:38 -0700 Date: Fri, 28 Jun 2019 13:40:35 +0100 From: Bruce Richardson To: David Marchand Cc: dev Message-ID: <20190628124035.GA347@bricha3-MOBL.ger.corp.intel.com> References: <20190529154132.49955-1-bruce.richardson@intel.com> <20190529154132.49955-4-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 3/4] eal: allow checking CPU flags by name 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jun 27, 2019 at 03:22:14PM +0200, David Marchand wrote: > On Wed, May 29, 2019 at 5:42 PM Bruce Richardson > <[1]bruce.richardson@intel.com> wrote: > > Rather than using enum values for CPU flags, which means the symbols > don't > exist on other architectures, provide a flag lookup by name, > allowing us to > unconditionally check for a CPU flag. > > Did you consider passing a string for the CPU architecture rather than > an enum? > It would have to be compared to RTE_ARCH in > rte_cpu_get_flagname_enabled. > Or to accomodate with x86_64/i686, this could be a cpu arch family. > This avoids adding a new C type that seems quite limited wrt its uses. > -- > David Marchand > I'm not sure I really see the value in having string names for the architecture values, I think it would be a lot more clunky to manage rather than having an enum value. The key difference vs the flags is that the flags are only valid per-architecture while the architecture defines can be globally valid, and secondly there is a finite, and small, number of architectures compared to the number of flags supported. If you feel strongly about it I can investigate it, but I'm not sure I see the value in doing so right now if the only benefit is avoiding the enum. /Bruce