From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 32651A3; Mon, 8 Apr 2019 15:38:53 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2019 06:38:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,325,1549958400"; d="scan'208";a="289716951" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.26.147]) ([10.252.26.147]) by orsmga004.jf.intel.com with ESMTP; 08 Apr 2019 06:38:49 -0700 To: Ray Kinsella , 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> From: "Burakov, Anatoly" Message-ID: <6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com> Date: Mon, 8 Apr 2019 14:38:48 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 08 Apr 2019 13:38:55 -0000 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] >> >> My worry here is that some API's get more attention than others, but >> requirements for freezing the API/ABI are applicable to all of them. >> >> Everyone loves discussing specifics of mbufs and dev API's, and I have >> no doubt that DPDK community can arrive at a consensus with regards to >> mbuf format etc. in a timely manner, since everyone has a vested >> interest in those covering their use cases. >> I have way less confidence >> in us possibly having saner and more maintainable platform >> initialization code, > > I think you are right, however its that same lack of enthusiasm that > would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0 > specification effort becoming an endless process, as it would always be > low on DPDK contributors priority list. > > Instead I recommend we set an API freeze date to focus peoples minds, > advertise what it means and contributors will respond and look after the > areas they care/are responsible for. > >> simply because any attempt to change those will >> likely be met with "please keep all of the old stuff working", which >> gets us right back to where we started. >> > > And to be honest that is a fair enough expectation from them, right? > To Stephen's if we need to break it, let's do it once more and then > never again. > 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 :) 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%. 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. -- 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 8B9C8A0096 for ; Mon, 8 Apr 2019 15:38:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 161734CA9; Mon, 8 Apr 2019 15:38:57 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 32651A3; Mon, 8 Apr 2019 15:38:53 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2019 06:38:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,325,1549958400"; d="scan'208";a="289716951" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.26.147]) ([10.252.26.147]) by orsmga004.jf.intel.com with ESMTP; 08 Apr 2019 06:38:49 -0700 To: Ray Kinsella , 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> From: "Burakov, Anatoly" Message-ID: <6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com> Date: Mon, 8 Apr 2019 14:38:48 +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: Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit 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: <20190408133848.tqNUjE_vbpkYpZ9yVsGMvrd3uGeZ7TDT5k1x0j1N7pU@z> 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] >> >> My worry here is that some API's get more attention than others, but >> requirements for freezing the API/ABI are applicable to all of them. >> >> Everyone loves discussing specifics of mbufs and dev API's, and I have >> no doubt that DPDK community can arrive at a consensus with regards to >> mbuf format etc. in a timely manner, since everyone has a vested >> interest in those covering their use cases. >> I have way less confidence >> in us possibly having saner and more maintainable platform >> initialization code, > > I think you are right, however its that same lack of enthusiasm that > would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0 > specification effort becoming an endless process, as it would always be > low on DPDK contributors priority list. > > Instead I recommend we set an API freeze date to focus peoples minds, > advertise what it means and contributors will respond and look after the > areas they care/are responsible for. > >> simply because any attempt to change those will >> likely be met with "please keep all of the old stuff working", which >> gets us right back to where we started. >> > > And to be honest that is a fair enough expectation from them, right? > To Stephen's if we need to break it, let's do it once more and then > never again. > 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 :) 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%. 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. -- Thanks, Anatoly