From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 65992A045E for ; Thu, 30 May 2019 12:11:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3BB881B957; Thu, 30 May 2019 12:11:27 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F10371B955 for ; Thu, 30 May 2019 12:11:25 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2019 03:11:24 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.64]) by fmsmga006.fm.intel.com with SMTP; 30 May 2019 03:11:20 -0700 Received: by (sSMTP sendmail emulation); Thu, 30 May 2019 11:11:18 +0100 Date: Thu, 30 May 2019 11:11:18 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: David Marchand , Stephen Hemminger , dev , Kevin Traynor , Neil Horman , Luca Boccassi Message-ID: <20190530101118.GA1107@bricha3-MOBL.ger.corp.intel.com> References: <20190408182510.16078-1-stephen@networkplumber.org> <20190529155141.5d773396@hermes.lan> <4005890.T4jVSnTFc5@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4005890.T4jVSnTFc5@xps> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v4 2/5] eal: add lcore accessors 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, May 30, 2019 at 09:40:08AM +0200, Thomas Monjalon wrote: > 30/05/2019 09:31, David Marchand: > > On Thu, May 30, 2019 at 12:51 AM Stephen Hemminger < > > stephen@networkplumber.org> wrote: > > > > > On Thu, 30 May 2019 00:46:30 +0200 > > > Thomas Monjalon wrote: > > > > > > > 23/05/2019 15:58, David Marchand: > > > > > From: Stephen Hemminger > > > > > > > > > > The fields of the internal EAL core configuration are currently > > > > > laid bare as part of the API. This is not good practice and limits > > > > > fixing issues with layout and sizes. > > > > > > > > > > Make new accessor functions for the fields used by current drivers > > > > > and examples. > > > > [...] > > > > > +DPDK_19.08 { > > > > > + global: > > > > > + > > > > > + rte_lcore_cpuset; > > > > > + rte_lcore_index; > > > > > + rte_lcore_to_cpu_id; > > > > > + rte_lcore_to_socket_id; > > > > > + > > > > > +} DPDK_19.05; > > > > > + > > > > > EXPERIMENTAL { > > > > > global: > > > > > > > > Just to make sure, are we OK to introduce these functions > > > > as non-experimental? > > > > > > They were in previous releases as inlines this patch converts them > > > to real functions. > > > > > > > > Well, yes and no. > > > > rte_lcore_index and rte_lcore_to_socket_id already existed, so making them > > part of the ABI is fine for me. > > > > rte_lcore_to_cpu_id is new but seems quite safe in how it can be used, > > adding it to the ABI is ok for me. > > It is used by DPAA and some test. > I guess adding as experimental is fine too? > I'm fine with both options, I'm just trying to apply the policy > we agreed on. Does this case deserve an exception? > While it may be a good candidate, I'm not sure how much making an exception for it really matters. I'd be tempted to just mark it experimental and then have it stable for the 19.11 release. What do we really lose by waiting a release to stabilize it?