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 E3E1CA05D3 for ; Tue, 23 Apr 2019 16:19:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1DE141B432; Tue, 23 Apr 2019 16:19:13 +0200 (CEST) Received: from relay0127.mxlogin.com (relay0127.mxlogin.com [199.181.239.127]) by dpdk.org (Postfix) with ESMTP id A7E061B431 for ; Tue, 23 Apr 2019 16:19:11 +0200 (CEST) Received: from filter002.mxroute.com (unknown [116.203.155.46]) by relay0127.mxlogin.com (Postfix) with ESMTP id CAD45CC1031B; Tue, 23 Apr 2019 09:19:10 -0500 (CDT) Received: from localhost (unknown [23.92.70.113]) by filter002.mxroute.com (Postfix) with ESMTPS id B985D3F0D0; Tue, 23 Apr 2019 14:19:09 +0000 (UTC) Received: from [192.55.54.44] by localhost with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hIwH3-0008Ki-VH; Tue, 23 Apr 2019 10:19:54 -0400 To: Stephen Hemminger , Jerin Jacob Kollanukkaran Cc: Bruce Richardson , Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , nd References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> <20190417115110.5cb70832@hermes.lan> 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: Date: Tue, 23 Apr 2019 15:19:04 +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: <20190417115110.5cb70832@hermes.lan> Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 7bit 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: <20190423141904.sko_PJ37WXDg-4fLhVA-fCupkpzWAI6XBRIhZk_Xhrc@z> On 17/04/2019 19:51, Stephen Hemminger wrote: > On Wed, 17 Apr 2019 17:46:34 +0000 > Jerin Jacob Kollanukkaran wrote: > >>> -----Original Message----- >>> From: dev On Behalf Of Bruce Richardson >>> Sent: Wednesday, April 17, 2019 2:07 PM >>> To: Honnappa Nagarahalli >>> Cc: dev@dpdk.org; Stephen Hemminger ; >>> Ananyev, Konstantin ; thomas@monjalon.net; >>> Ray Kinsella ; nd >>> Subject: Re: [dpdk-dev] ABI and inline functions >>> >>>> 2) Every function that is not in the direct datapath (fastpath?) >>>> should not be inline. Exceptions or things like rx/tx burst, ring >>>> enqueue/dequeue, and packet alloc/free - Stephen >>> >>> Agree with this. Anything not data path should not be inline. The next question >>> then is for data path items how to determine whether they need to be inline or >>> not. In general my rule-of-thumb: >>> * anything dealing with bursts of packets should not be inline >> >> # I think, we need consider the how fat is the function too, >> If it is light weight, probably we need to make it inline Well if it light weight however it is not dealing directly with packets, probably does not matter if is not-inline? >> # Except the forward case, In real world use case, it is not trivial make large >> burst of packet to process it even though function prototype burst. >> We may need to consider that >> # For the given function if some argument is used with inline other function, >> probably no point in making that function alone inline as the structure >> is exposed in some other function. >> >>> * anything what works with single packet at a time should be inline >>> >>>> In this context, does it make sense to say that we will maintain API >>>> compatibility rather than saying ABI compatibility? This will also >>>> send the right message to the end users. >>>> >>> I would value ABI compatibility much higher than API compatibility. If someone >>> is recompiling the application anyway, making a couple of small changes (large >>> rework is obviously a different issue) to the code should not be a massive issue, I >>> hope. On the other hand, ABI compatibility is needed to allow seamless update >>> from one version to another, and it's that ABI compatiblity that allows distro's to >>> pick up our latest and greatest versions. >> >> IMO, We have two primary use case for DPDK >> >> 1) NFV kind of use case where the application needs to run on multiple platform >> without recompiling it. >> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated >> Controller used. For fixed appliance use case, end user care more of performance >> than ABI compatibility as it easy to recompile the end user application vs the cost of >> hitting performance impact. > > Nobody cares about compatiablity until they have to the first security update. > +1