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 424E5A0096 for ; Thu, 9 May 2019 11:51:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 47305493D; Thu, 9 May 2019 11:51:14 +0200 (CEST) Received: from relay0189.mxlogin.com (relay0189.mxlogin.com [199.181.239.189]) by dpdk.org (Postfix) with ESMTP id B43D43977 for ; Thu, 9 May 2019 11:51:12 +0200 (CEST) Received: from filter001.mxrelay.co (unknown [116.203.155.46]) by relay0189.mxlogin.com (Postfix) with ESMTP id 979E1CC70314; Thu, 9 May 2019 04:51:11 -0500 (CDT) Received: from localhost (unknown [23.92.70.113]) by filter001.mxrelay.co (Postfix) with ESMTPS id 297E81000D3; Thu, 9 May 2019 09:51:09 +0000 (UTC) Received: from jfdmzpr04-ext.jf.intel.com ([134.134.139.73]) by localhost with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hOfiU-0007Fp-VD; Thu, 09 May 2019 05:51:55 -0400 To: Thomas Monjalon , "Burakov, Anatoly" 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> From: Ray Kinsella Openpgp: preference=signencrypt Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <28911350-06c1-2479-8e2f-7b372d8f1df7@ashroe.eu> Date: Thu, 9 May 2019 10:50:58 +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: <3072107.mBd7PBc0fB@xps> Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu 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: <20190509095058.hftTSLdNZNjGfjPS31sLrqAqHMRsIjyoHTunWFQ7T4Y@z> 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.