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 C1177A0471 for <public@inbox.dpdk.org>; Thu, 20 Jun 2019 22:16:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7CEEE1D49A; Thu, 20 Jun 2019 22:16:55 +0200 (CEST) Received: from mail-vs1-f66.google.com (mail-vs1-f66.google.com [209.85.217.66]) by dpdk.org (Postfix) with ESMTP id 452A91D498 for <dev@dpdk.org>; Thu, 20 Jun 2019 22:16:54 +0200 (CEST) Received: by mail-vs1-f66.google.com with SMTP id 2so2360174vso.8 for <dev@dpdk.org>; Thu, 20 Jun 2019 13:16:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vaYeWGk6/q2YDVE2rFThCA9GSEaMRicZh59tiKfGSOg=; b=A6+kpPlLNJGd7Ftf1CkjWmmR18IGHYayg2cFuhglioj38BMr2CWfbiWSZVYJavewZ0 SXluy4k6jww6mf0QjwPSyyyVSTx1iAPfU9YgsGBqBTwXdOvKLM2SLV07w/Um5UNbk+XE bqfYfdvtu3NO/tS9JiDI82RrEZ36PWHDlbO/BZiL4XhOEFdlydlc44mxhnBg3d6W4J7A OxIt9i2ws/m7DJIQXJTz3pu4Thv/ToHYMes5TY6R4lVheQSyhuRRpVKEGbx3RqgUAc7X lsBngnsRVh0R3f8SEukFUjYozqWEw8FT5QmAg4FppQUiDivuuVhOFmX6jX+btYFbdktY 63GA== X-Gm-Message-State: APjAAAW3eHh5DqtumEi/Npo6xOBnAo9J6mXKyzcFxkALLbVURhdMb/MB Uk2QrTaHqBuFHB5Lz3Sgvh3FPSTvTNMgj776Fet6sQ== X-Google-Smtp-Source: APXvYqxovoax3Haf8Wb//3o4hgnCFOx2IZj9YCaVP6a1uFKH/Y9jRc8529yFigFZFOhq+ONBXiUw6WghlUUf1hlCfhc= X-Received: by 2002:a67:f998:: with SMTP id b24mr61505726vsq.180.1561061813694; Thu, 20 Jun 2019 13:16:53 -0700 (PDT) MIME-Version: 1.0 References: <20190620164206.3972-1-gage.eads@intel.com> <f7tv9x0ru55.fsf@dhcp-25.97.bos.redhat.com> <CAJFAV8x7L8UjcjSX=JdG4Vv3nvdpS=TNzHCkaBHNOqTXf13RsQ@mail.gmail.com> In-Reply-To: <CAJFAV8x7L8UjcjSX=JdG4Vv3nvdpS=TNzHCkaBHNOqTXf13RsQ@mail.gmail.com> From: David Marchand <david.marchand@redhat.com> Date: Thu, 20 Jun 2019 22:16:42 +0200 Message-ID: <CAJFAV8xV1dXz3=a5pzyKvnUAqKMZWxQp0f+tTtEAz=ofWYrc0A@mail.gmail.com> To: Aaron Conole <aconole@redhat.com> Cc: Gage Eads <gage.eads@intel.com>, dev <dev@dpdk.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>, Van Haaren Harry <harry.van.haaren@intel.com>, Nikhil Rao <nikhil.rao@intel.com>, Erik Gabriel Carrillo <erik.g.carrillo@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Bruce Richardson <bruce.richardson@intel.com>, Pablo de Lara <pablo.de.lara.guarch@intel.com>, Adrien Mazarguil <adrien.mazarguil@6wind.com> Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable 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, Jun 20, 2019 at 9:45 PM David Marchand <david.marchand@redhat.com> wrote: > > > On Thu, Jun 20, 2019 at 8:26 PM Aaron Conole <aconole@redhat.com> wrote: > >> Gage Eads <gage.eads@intel.com> writes: >> >> > The functions rte_service_may_be_active(), rte_service_lcore_attr_get(), >> > and rte_service_attr_reset_all() were introduced nearly a year ago in >> DPDK >> > 18.08. They can be considered non-experimental for the 19.08 release. >> > >> > rte_service_may_be_active() is used by eventdev and the sw PMD, and this >> > commit allows them to not need any experimental API. >> > >> > Signed-off-by: Gage Eads <gage.eads@intel.com> >> > --- >> > drivers/event/sw/Makefile | 1 - >> > drivers/event/sw/meson.build | 1 - >> > lib/librte_eal/common/include/rte_service.h | 15 +++------------ >> > lib/librte_eal/common/rte_service.c | 6 +++--- >> > lib/librte_eal/rte_eal_version.map | 6 +++--- >> > lib/librte_eventdev/Makefile | 1 - >> > lib/librte_eventdev/meson.build | 1 - >> > 7 files changed, 9 insertions(+), 22 deletions(-) >> > >> > diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile >> > index 81236a392..c6600e836 100644 >> > --- a/drivers/event/sw/Makefile >> > +++ b/drivers/event/sw/Makefile >> > @@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk >> > LIB = librte_pmd_sw_event.a >> > >> > # build flags >> > -CFLAGS += -DALLOW_EXPERIMENTAL_API >> > CFLAGS += -O3 >> > CFLAGS += $(WERROR_FLAGS) >> > # for older GCC versions, allow us to initialize an event using >> > diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build >> > index 30d221647..985012219 100644 >> > --- a/drivers/event/sw/meson.build >> > +++ b/drivers/event/sw/meson.build >> > @@ -1,7 +1,6 @@ >> > # SPDX-License-Identifier: BSD-3-Clause >> > # Copyright(c) 2017 Intel Corporation >> > >> > -allow_experimental_apis = true >> >> I don't think you can remove these. There are still some experimental >> APIs (f.e. the rename for rte_cryptodev_sym_session_get_private_data >> marked that function as experimental and it will cause build breakage). >> >> Maybe I'm mis understanding it? It would be good to get verification >> from Bruce whether that API should not be marked as experimental (it was >> just a rename, so not sure...) - maybe that's a follow up for this >> patch? >> >> See: https://travis-ci.com/ovsrobot/dpdk/jobs/209722145 for an example >> >> The odd thing is I only see it on the clang builds - perhaps it's a >> missing definition for the clang compiler. >> > > Erf, it looks like the __rte_experimental tag is affected by the order in > the declaration of the symbol. > > --- a/lib/librte_cryptodev/rte_cryptodev.h > +++ b/lib/librte_cryptodev/rte_cryptodev.h > @@ -1245,7 +1245,7 @@ struct rte_cryptodev_asym_session * > __rte_experimental > * - On success return pointer to user data. > * - On failure returns NULL. > */ > -void * __rte_experimental > +__rte_experimental void * > rte_cryptodev_sym_session_get_user_data( > struct rte_cryptodev_sym_session > *sess); > > https://hastebin.com/micomogoqi.cs Does it mean that the "void *" type had been marked as deprecated with the previous syntax? Requesting compiler experts assistance :-) -- David Marchand