From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 45DA337B7 for ; Thu, 9 May 2019 11:37:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 02:37:53 -0700 X-ExtLoop1: 1 Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.251.91.208]) ([10.251.91.208]) by fmsmga001.fm.intel.com with ESMTP; 09 May 2019 02:37:51 -0700 To: Bruce Richardson Cc: David Marchand , Stephen Hemminger , Erik Gabriel Carrillo , Thomas Monjalon , dev References: <1557355686-4216-1-git-send-email-erik.g.carrillo@intel.com> <20190508181137.04112fd4@xps13> <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <7a9bd784-fdf9-75a7-8a5e-f7c348112fce@intel.com> Date: Thu, 9 May 2019 10:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Thu, 09 May 2019 09:37:54 -0000 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. -- Thanks, Anatoly 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 7FB88A0096 for ; Thu, 9 May 2019 11:37:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 66D93493D; Thu, 9 May 2019 11:37:55 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 45DA337B7 for ; Thu, 9 May 2019 11:37:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 02:37:53 -0700 X-ExtLoop1: 1 Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.251.91.208]) ([10.251.91.208]) by fmsmga001.fm.intel.com with ESMTP; 09 May 2019 02:37:51 -0700 To: Bruce Richardson Cc: David Marchand , Stephen Hemminger , Erik Gabriel Carrillo , Thomas Monjalon , dev References: <1557355686-4216-1-git-send-email-erik.g.carrillo@intel.com> <20190508181137.04112fd4@xps13> <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <7a9bd784-fdf9-75a7-8a5e-f7c348112fce@intel.com> Date: Thu, 9 May 2019 10:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190509090652.GB57@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit 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: <20190509093751.EfvW8zDv6mfaF8PD31rndCazm79ZGJG01nPABmdOMTU@z> 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. -- Thanks, Anatoly