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 9635BA0096 for ; Fri, 10 May 2019 16:42:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 798415B26; Fri, 10 May 2019 16:42:42 +0200 (CEST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 60CE45B1E for ; Fri, 10 May 2019 16:42:41 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id z26so3347573pfg.6 for ; Fri, 10 May 2019 07:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TVyaZolRRA8xVdqoSWMcU6LI0ZZaBY4O6FmyEqvzabM=; b=tDlnqGEhnBgCoTpJ5S8Q2tF06RQ6SIXRnqs0WYxZTdNnh24Tk6Xihxwxf+fQniGBiu 9MDZz2KkIWO7U4f6VRB/+tiZB6HVvBM0VxnsZeoHMgpPUjW2zc8QdklBGCticbhjPEEW T30svgGWj+IZw9AJT5bqyD6yKDWSCPni1TfQVvSuzVngSblyPuwQB/u5gqXSBbe0Crsk OhuFiR16y9S6DwLmiQn30bYwVFrckHS2UIz0dCsjRHHCmVkA6POVtsFYa+vHz7Fdgx/V 2m2AIH4V5t3UxEXi8SFEyaMr5i1aBcmuMAXDqFBqidAyRr++X3y0slrAnuxR3uHO/PG8 TAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TVyaZolRRA8xVdqoSWMcU6LI0ZZaBY4O6FmyEqvzabM=; b=bz22QIBIL56+BMCiJOUR+3eIqxqD3ON5Gvq11sdHpGpjjqEdfYB+gtc2t9qQ1RXuVg yQ4RkQdcxwnMv4Mxiwp7ChgjNBcnIjV1aWb592ceMZYTbdkFWpOWyl2npnGFA40KRwn/ EjzoswIFG0YtjVxRqpklTGHIMYGUpUZzcNl65rFtvK6Jvx7MsCzXtk0A+RSejnSmlg/v l8RpVO7mLqjU2aQf4AjuxEWlfrgiRMgpdR8TWoSBdXQUgwWjyoqOXWAUnOQW7Wuy8q+L hPjwb4Ir1FYCSi9qOs6D6UI61gzwD4HZ2csnj0/C45OIAP8L3YVVuU+W7pnFt2YF4TYM P22A== X-Gm-Message-State: APjAAAVL1Ynm47ngQOu2/lnhJwO7Pks1pvVvicUzFyHf2nr6NS/5T/4L ZCgkLl7l/JK+XRQGsVuHodl3ZA== X-Google-Smtp-Source: APXvYqzuF4Eksgfn+mSB87eESFuq09dNOTmkGtjqO704JGRDz4VqX8C79yfDgpYVo2KG15XW76dRpg== X-Received: by 2002:a63:5264:: with SMTP id s36mr9434428pgl.258.1557499359211; Fri, 10 May 2019 07:42:39 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id v64sm7582696pfv.106.2019.05.10.07.42.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 May 2019 07:42:39 -0700 (PDT) Date: Fri, 10 May 2019 07:42:31 -0700 From: Stephen Hemminger To: "Burakov, Anatoly" Cc: Ray Kinsella , Thomas Monjalon , Bruce Richardson , David Marchand , Erik Gabriel Carrillo , dev Message-ID: <20190510074231.483d7f48@hermes.lan> In-Reply-To: References: <1557355686-4216-1-git-send-email-erik.g.carrillo@intel.com> <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> <7a9bd784-fdf9-75a7-8a5e-f7c348112fce@intel.com> <3072107.mBd7PBc0fB@xps> <28911350-06c1-2479-8e2f-7b372d8f1df7@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup 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" Message-ID: <20190510144231.Cw_OJeUCNOv3HA5onqt17_6Z7quxdXXJcfPg4Z2R-h4@z> On Thu, 9 May 2019 11:08:30 +0100 "Burakov, Anatoly" wrote: > On 09-May-19 10:50 AM, Ray Kinsella wrote: > > > > > > On 09/05/2019 10:38, Thomas Monjalon wrote: > >> 09/05/2019 11:37, Burakov, Anatoly: > >>> On 09-May-19 10:06 AM, Bruce Richardson wrote: > >>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote: > >>>>> On 09-May-19 8:05 AM, David Marchand wrote: > >>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger > >>>>>> > wrote: > >>>>>> > >>>>>> On Wed, 8 May 2019 17:48:06 -0500 > >>>>>> Erik Gabriel Carrillo >>>>>> > wrote: > >>>>>> > >>>>>> > Due to an upcoming fix to allow the timer library to safely free its > >>>>>> > allocations during the finalize() call[1], an ABI change will be > >>>>>> > required. A new lock will be added to the rte_mem_config structure, > >>>>>> > which will be used by the timer library to synchronize init/finalize > >>>>>> > calls among multiple processes. > >>>>>> > > >>>>>> > [1] http://patches.dpdk.org/patch/53334/ > >>>>>> > > >>>>>> > Signed-off-by: Erik Gabriel Carrillo >>>>>> > > >>>>>> > --- > >>>>>> > doc/guides/rel_notes/deprecation.rst | 4 ++++ > >>>>>> > 1 file changed, 4 insertions(+) > >>>>>> > > >>>>>> > diff --git a/doc/guides/rel_notes/deprecation.rst > >>>>>> b/doc/guides/rel_notes/deprecation.rst > >>>>>> > index b47c8c2..7551383 100644 > >>>>>> > --- a/doc/guides/rel_notes/deprecation.rst > >>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst > >>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices > >>>>>> > > >>>>>> > + ``rte_eal_devargs_type_count`` > >>>>>> > > >>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a > >>>>>> new lock that > >>>>>> > + will allow the timer subsystem to safely release its > >>>>>> allocations at cleanup > >>>>>> > + time. This will result in an ABI break. > >>>>>> > + > >>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and > >>>>>> ``rte_vfio_dma_unmap`` APIs which > >>>>>> > have been replaced with ``rte_dev_dma_map`` and > >>>>>> ``rte_dev_dma_unmap`` > >>>>>> > functions. The due date for the removal targets DPDK 20.02. > >>>>>> > >>>>>> NAK > >>>>>> > >>>>>> Please go to the effort of making rte_mem_config not part of the > >>>>>> visible ABI. > >>>>>> Then change it. > >>>>>> > >>>>>> > >>>>>> +1. > >>>>> > >>>>> I agree on principle, however this won't solve the issue. It doesn't need to > >>>>> be externally visible, but that's not all of its problems - it's also shared > >>>>> between processes so there's an ABI contract between primary and secondary > >>>>> too. This means that, even if the structure itself is not public, any > >>>>> changes to it will still result in an ABI break. That's the nature of our > >>>>> shared memory. > >>>>> > >>>>> In other words, if your goal is to avoid ABI breaks on changing this > >>>>> structure, making it internal won't help in the slightest. > >>>>> > >>>> > >>>> Is there an ABI contract between primary and secondary. I always assumed > >>>> that if using secondary processes the requirement (though undocumented) was > >>>> that both had to be linked against the exact same versions of DPDK? > >>>> > >>> > >>> The fact that it's undocumented means we can't assume everyone will do > >>> that :) > >>> > >>> If the community agrees that primary/secondary processes should always > >>> use the same DPDK version (regardless of static/dynamic builds etc.), > >>> then this problem would probably be solved. > >> > >> +1 to document that primary/secondary with different DPDK versions > >> is not supported. > >> > > > > +1, > > > > but I think we need to go farther - we need a secondary process to check > > with the primary process. > > We can't assume everyone will read the documentation. > > > > That easily can be done, yes. > FYI - I submitted patches to make lcore_config private. These patches should handle mem_config. And I started on making eal_config private (but mem_config got in the way). Other candidates are the internals behind ethdev and devices.