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 59B51A0096 for ; Thu, 9 May 2019 11:07:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE46149E0; Thu, 9 May 2019 11:06:59 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id BA54037B7 for ; Thu, 9 May 2019 11:06:57 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 02:06:56 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.251.93.144]) by fmsmga005.fm.intel.com with SMTP; 09 May 2019 02:06:54 -0700 Received: by (sSMTP sendmail emulation); Thu, 09 May 2019 10:06:53 +0100 Date: Thu, 9 May 2019 10:06:53 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: David Marchand , Stephen Hemminger , Erik Gabriel Carrillo , Thomas Monjalon , dev Message-ID: <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> References: <1557355686-4216-1-git-send-email-erik.g.carrillo@intel.com> <20190508181137.04112fd4@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) 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: <20190509090653.V9_V27WpO9vqe6rJ4-1HHKEdakjX7xrYViW9VJkuATY@z> 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?