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 66B13A05D3 for ; Wed, 24 Apr 2019 14:23:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6BB831B509; Wed, 24 Apr 2019 14:23:06 +0200 (CEST) Received: from relay0155.mxlogin.com (relay0155.mxlogin.com [199.181.239.155]) by dpdk.org (Postfix) with ESMTP id E0EBA1B20E for ; Wed, 24 Apr 2019 14:23:04 +0200 (CEST) Received: from filter001.mxrelay.co (unknown [94.130.183.33]) by relay0155.mxlogin.com (Postfix) with ESMTP id AF887CC4031F; Wed, 24 Apr 2019 07:23:03 -0500 (CDT) Received: from localhost (unknown [23.92.70.113]) by filter001.mxrelay.co (Postfix) with ESMTPS id F0986100060; Wed, 24 Apr 2019 12:23:00 +0000 (UTC) Received: from jfdmzpr03-ext.jf.intel.com ([134.134.139.72]) by localhost with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hJGwD-00069b-Pu; Wed, 24 Apr 2019 08:23:46 -0400 To: "Burakov, Anatoly" , Bruce Richardson , Honnappa Nagarahalli Cc: "dev@dpdk.org" , Stephen Hemminger , "Ananyev, Konstantin" , "thomas@monjalon.net" , nd References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> <20190418102811.GB1817@bricha3-MOBL.ger.corp.intel.com> <2ec4da50-d874-865a-6bcc-916ac676be39@ashroe.eu> <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> 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: <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> Date: Wed, 24 Apr 2019 13:22:55 +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: <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] ABI and inline functions 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: <20190424122255.2YD_C2aoKWltuYpnHAw89J1_8Q5Fc6wTwd_t0yQPbgc@z> On 24/04/2019 12:08, Burakov, Anatoly wrote: > On 23-Apr-19 3:12 PM, Ray Kinsella wrote: >> >> >> On 18/04/2019 11:28, Bruce Richardson wrote: >>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote: >>>>> >>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote: >>>>>> Hello, >>>>>>     There was a conversation [1] in the context of RCU library. I >>>>>> thought >>>>>> it needs participation from broader audience. Summary for the context >>>>>> (please look at [1] for full details) >>>>>> >>>>> >>>>> Thanks for kicking off this discussion >>>>> >>>>>> 1) How do we provide ABI compatibility when the code base contains >>>>> inline functions? Unless we freeze development in these inline >>>>> functions and >>>>> corresponding structures, it might not be possible to claim ABI >>>>> compatibility. >>>>> Application has to be recompiled. >>>>> >>>>> I agree that in some cases the application "might" need to be >>>>> recompiled, >>>>> but on the other hand I also think that there are many cases where ABI >>>>> function versioning can still be used to mitigate things. For >>>>> example, if we >>>>> think of a couple of various scenarios: >>>>> >>>>> 1. If everything is inline and variables are allocated by app, e.g. >>>>> spinlock on stack, then there is no issue as everything is application >>>>> contained. >>>> If there is a bug fix which requires the structure to change, the >>>> application would need to recompile. I guess you are talking about a >>>> scenario when nothing changed in the inline function/variables. >>>> >>> >>> If the application wants the bugfix, then yes. However, if the app is >>> unaffected by the bug, then it should have the option of updating DPDK >>> without a recompile. >> >> I would also imagine that should be an extremely rare case, that a >> bugfix would require a structure change ... perhaps for an alignment >> issues? > > Multiprocess threading issues is one case i've had to do that more than > once. Another reason to dislike multi process I guess. > > > > >> >> The reality is that most other system libraries provide strong >> guarantees ... to date we have provided very little. >> > > To our credit, the libraries you're likely referring to aren't trying to > reimplement the Linux kernel :) I don't think we do these API/ABI breaks > just because we like doing them - DPDK is complex, and getting > everything right the first time *and* allowing for future evolution is > not a trivial undertaking. > > > To me, part of the problem is that DPDK is an "everything and the > kitchen sink" kind of library where there is a bunch of drivers, a whole > quasi-OS layer of dealing with hardware in a cross-platform manner, a > separate memory management system, a bunch of libraries such as hash/lpm > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a > library" would concentrate on doing one thing well. DPDK, on the other > hand, tries to do *everything* well. The sheer breadth of DPDK's scope > is, i think, contributing to the breakages. If you keep 99% of your > libraries stable between version, but there's a small ABI tweak in an > LPM library, the entire DPDK stability gets invalidated. Well I guess DPDK is no more complex than Java or .NET Framework in that respect, as these also feature OS-layers, memory management systems, application frameworks, primitives etc but do manage to give their consumers strong guarantee's on API stability. Clearly ABI stability has a no meaning when you always being JIT compiled. I understand that doing everything right the first time, allowing for future evolution, while keep ABI/APIs relatively stable is a tough ask. I would propose that API's marked as "experimental" be given greater freedom to change to give time of API's to bake, so they don't need to be always "right first time", that there is wriggle room for these. I would also propose more use of ABI Versioning to enable evolution of DPDK while preserving backward compatibility. > > Perhaps limiting DPDK's scope would help with this as well. I agree. > >> >>> >>> Regards, >>> /Bruce >>> >> > >