From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4502EC4363C for ; Wed, 7 Oct 2020 10:52:40 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 993362137B for ; Wed, 7 Oct 2020 10:52:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 993362137B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 46A791B65F; Wed, 7 Oct 2020 12:52:29 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 5EA054C9D for ; Wed, 7 Oct 2020 12:52:22 +0200 (CEST) IronPort-SDR: +QsKxwFLZoKdGUITqbfHCbmkb1gzOBDPHRmKZv0gYcnhwkUo1rnvZLv4egercBcDV8en4JF+AR vdv5OYXgN9Rw== X-IronPort-AV: E=McAfee;i="6000,8403,9766"; a="161500713" X-IronPort-AV: E=Sophos;i="5.77,346,1596524400"; d="scan'208";a="161500713" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2020 03:52:18 -0700 IronPort-SDR: Aty91eySZz99FGFEuKG1bXNrGrupXUCe+BdQQ5b3L4StHT43R7KIIKTmwTmPT0wcJootcV95S6 pxd2R99p+ErQ== X-IronPort-AV: E=Sophos;i="5.77,346,1596524400"; d="scan'208";a="527896873" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.1.245]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 07 Oct 2020 03:52:16 -0700 Date: Wed, 7 Oct 2020 11:52:12 +0100 From: Bruce Richardson To: "Power, Ciara" Cc: Olivier Matz , "dev@dpdk.org" , Ray Kinsella , Neil Horman Message-ID: <20201007105212.GE680@bricha3-MOBL.ger.corp.intel.com> References: <20200807155859.63888-1-ciara.power@intel.com> <20200930130415.11211-1-ciara.power@intel.com> <20200930130415.11211-2-ciara.power@intel.com> <20201006093217.GG21395@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3 01/18] eal: add max SIMD bitwidth 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 Wed, Oct 07, 2020 at 11:47:34AM +0100, Power, Ciara wrote: > Hi Olivier, > > Thanks for reviewing, some comments below. > > > >-----Original Message----- > >From: Olivier Matz > >Sent: Tuesday 6 October 2020 10:32 > >To: Power, Ciara > >Cc: dev@dpdk.org; Ray Kinsella ; Neil Horman > > > >Subject: Re: [dpdk-dev] [PATCH v3 01/18] eal: add max SIMD bitwidth > > > >Hi Ciara, > > > >Please find some comments below. > > > >On Wed, Sep 30, 2020 at 02:03:57PM +0100, Ciara Power wrote: > >> This patch adds a max SIMD bitwidth EAL configuration. The API allows > >> for an app to set this value. It can also be set using EAL argument > >> --force-max-simd-bitwidth, which will lock the value and override any > >> modifications made by the app. > >> > >> Signed-off-by: Ciara Power > >> > >> --- > >> v3: > >> - Added enum value to essentially disable using max SIMD to choose > >> paths, intended for use by ARM SVE. > >> - Fixed parsing bitwidth argument to return an error for values > >> greater than uint16_t. > >> v2: Added to Doxygen comment for API. > >> --- > > > > >> > >> +uint16_t > >> +rte_get_max_simd_bitwidth(void) > >> +{ > >> +const struct internal_config *internal_conf = > >> +eal_get_internal_configuration(); > >> +return internal_conf->max_simd_bitwidth.bitwidth; > >> +} > > > >Should the return value be enum rte_max_simd_t? > >If not, do we really need the enum definition? > > > > I kept the return value and param value below as uint16_t to allow for arbitrary values, > and will allow it be more flexible for future additions as new enums won't need to be added. > For the set function below, this is used when a user passes the EAL command line flag, which > passes an integer value rather than an enum one. > The enums are useful when checking the max_simd_bitwidth in drivers/libs, for example using > "RTE_MAX_256_SIMD" instead of "256" in the condition checks. > So basically these enum values are #defines for readability, just in enum form, right?