From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 808B43977 for ; Thu, 9 May 2019 12:08:34 +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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 03:08:33 -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 03:08:31 -0700 To: Ray Kinsella , Thomas Monjalon Cc: Bruce Richardson , David Marchand , Stephen Hemminger , Erik Gabriel Carrillo , dev 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> From: "Burakov, Anatoly" Message-ID: Date: Thu, 9 May 2019 11:08:30 +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: <28911350-06c1-2479-8e2f-7b372d8f1df7@ashroe.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: , X-List-Received-Date: Thu, 09 May 2019 10:08:35 -0000 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. -- 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 8066DA0096 for ; Thu, 9 May 2019 12:08:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4573249E0; Thu, 9 May 2019 12:08:36 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 808B43977 for ; Thu, 9 May 2019 12:08:34 +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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 03:08:33 -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 03:08:31 -0700 To: Ray Kinsella , Thomas Monjalon Cc: Bruce Richardson , David Marchand , Stephen Hemminger , Erik Gabriel Carrillo , dev 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> From: "Burakov, Anatoly" Message-ID: Date: Thu, 9 May 2019 11:08:30 +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: <28911350-06c1-2479-8e2f-7b372d8f1df7@ashroe.eu> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US 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: <20190509100830.wgugP3QynuA6N2LF87B_6Meetcq6mWQGRgCHu_kNBe8@z> 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. -- Thanks, Anatoly