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 dpdk.space (Postfix) with ESMTP id 65992A045E
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: David Marchand <david.marchand@redhat.com>,
Stephen Hemminger <stephen@networkplumber.org>, dev <dev@dpdk.org>,
Kevin Traynor <ktraynor@redhat.com>, Neil Horman <nhorman@tuxdriver.com>,
Luca Boccassi <bluca@debian.org>
Message-ID: <20190530101118.GA1107@bricha3-MOBL.ger.corp.intel.com>
References: <20190408182510.16078-1-stephen@networkplumber.org>
<20190529155141.5d773396@hermes.lan>
<CAJFAV8zjxMujBD-EWf=1g8z7NxZT1O4gBUrLSC8qPajqg1iroA@mail.gmail.com>
<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 <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 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 <thomas@monjalon.net> wrote:
> > >
> > > > 23/05/2019 15:58, David Marchand:
> > > > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > > >
> > > > > 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?