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 35484A0096 for ; Tue, 9 Apr 2019 11:42:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2DD05F1D; Tue, 9 Apr 2019 11:42:37 +0200 (CEST) Received: from relay0130.mxlogin.com (relay0130.mxlogin.com [199.181.239.130]) by dpdk.org (Postfix) with ESMTP id AA17D5B40; Tue, 9 Apr 2019 11:42:36 +0200 (CEST) Received: from filter001.mxrelay.co (unknown [94.130.183.33]) by relay0130.mxlogin.com (Postfix) with ESMTP id 7F179CC2030D; Tue, 9 Apr 2019 04:42:35 -0500 (CDT) Received: from localhost (unknown [23.92.70.113]) by filter001.mxrelay.co (Postfix) with ESMTPS id C914D1008FA; Tue, 9 Apr 2019 09:42:32 +0000 (UTC) Received: from jfdmzpr06-ext.jf.intel.com ([134.134.139.75]) by localhost with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hDnHg-000810-RJ; Tue, 09 Apr 2019 05:43:17 -0400 To: "Burakov, Anatoly" , Thomas Monjalon Cc: techboard@dpdk.org, Bruce Richardson , dev@dpdk.org, Kevin Traynor References: <455a61b4-891d-eaaf-d784-2be884bcacbd@intel.com> <7166381.CkH77a7QuE@xps> <5e27f573-bbf5-30f1-73ee-d35fc5191632@ashroe.eu> <6a9bf695-b287-9e5e-358c-d6c3f93db045@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: <473d32c5-d10e-af49-7140-b1e3bf010831@ashroe.eu> Date: Tue, 9 Apr 2019 10:42:24 +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: <6a9bf695-b287-9e5e-358c-d6c3f93db045@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] [dpdk-techboard] DPDK ABI/API Stability 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: <20190409094224.kKM56c1vO59GNCoA0igOFccDoymBZMshLkFjV8W9Gt8@z> On 08/04/2019 14:38, Burakov, Anatoly wrote: > On 08-Apr-19 2:00 PM, Ray Kinsella wrote: >> >> >> On 08/04/2019 11:15, Burakov, Anatoly wrote: >>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote: >>>> On 07/04/2019 10:48, Thomas Monjalon wrote: >>>>> 04/04/2019 16:07, Burakov, Anatoly: >>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote: >>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote: >>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: >>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote: >>>> [SNIP] >> [SNIP] [SNIP] >> > > Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0 > specification" i don't mean there literally should be a document with a > formal specification :) When I hear the word specification I think encyclopedia-like stacks of paper. > > Rather, i'm thinking more along the lines of, let's take a look at what > we have, and think of ways we can reduce the amount of code and improve > things without causing major inconveniences to great majority of users. > As in, if we want to "break once more and then never again", then maybe > instead of small incremental fixes here and there, we could actually do > a more drastic change that keeps perhaps 90% users happy instead of > 100%, but which reduces maintenance/validation effort from 100% down to > 30%. Agreed - all I would propose on top of this is that we give ourselves a real deadline. The DPDK API has been iterating since 2012 and while we can spare a few more months to do tidy-up and get it right, we _do_ need to draw a line in the sand at the same time. > > As a concrete proposal, my number one dream would be to see multiprocess > gone. I also recall desire for "DPDK to be more lightweight", and i > maintain that DPDK *cannot* be lightweight if we are to support > multiprocess - we can have one or the other, but not both. However, > realistically, i don't think dropping multiprocess is ever going to > happen - not only it is too entrenched in DPDK use cases, it is actually > quite useful despite its flaws. > > However, what *could* be realistic is to trim down complexity in EAL > init and system code in general - to me (again, a concrete proposal!), > that would be dropping igb_uio and supporting upstream kernel modules > only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit > support and legacy mem modes, and perhaps bumping kernel version and > removing some compatibility code as well. This would remove potentially > thousands of lines of code and keep EAL cleaner and more maintainable: > right now, we have two different hotplug mechanisms (UIO and VFIO), lots > of different memory/interrupt modes, etc., for no reason that is readily > apparent to me. > > So, as you can see, an effort to review and delineate what we want to > support would be necessary if we want to ease the maintenance burden for > either myself or anyone that inherits this code, as well as reducing the > number of moving parts and, as a consequence, validation effort and > amount of bugs. We can't simply do it in a random release "just > because", but if we were to "break once more and then never again", > perhaps this is something that could be considered. >