DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Ray Kinsella <mdr@ashroe.eu>, Thomas Monjalon <thomas@monjalon.net>
Cc: techboard@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,
	dev@dpdk.org, Kevin Traynor <ktraynor@redhat.com>
Subject: Re: [dpdk-dev] [dpdk-techboard]  DPDK ABI/API Stability
Date: Mon, 8 Apr 2019 14:38:48 +0100	[thread overview]
Message-ID: <6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com> (raw)
Message-ID: <20190408133848.tqNUjE_vbpkYpZ9yVsGMvrd3uGeZ7TDT5k1x0j1N7pU@z> (raw)
In-Reply-To: <c79ff6e8-6b53-66e9-9e34-76f2f86079f7@ashroe.eu>

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

  parent reply	other threads:[~2019-04-08 13:38 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 15:42 [dpdk-dev] " Ray Kinsella
2019-04-03 15:42 ` Ray Kinsella
2019-04-03 19:53 ` Luca Boccassi
2019-04-03 19:53   ` Luca Boccassi
2019-04-04  9:29 ` Burakov, Anatoly
2019-04-04  9:29   ` Burakov, Anatoly
2019-04-04 10:54   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54     ` Bruce Richardson
2019-04-04 12:02     ` Luca Boccassi
2019-04-04 12:02       ` Luca Boccassi
2019-04-04 13:05       ` Ray Kinsella
2019-04-04 13:05         ` Ray Kinsella
2019-04-04 13:10         ` Bruce Richardson
2019-04-04 13:10           ` Bruce Richardson
2019-04-05 13:25           ` Ray Kinsella
2019-04-05 13:25             ` Ray Kinsella
2019-04-07  9:37             ` Thomas Monjalon
2019-04-07  9:37               ` Thomas Monjalon
2019-04-04 13:21         ` Luca Boccassi
2019-04-04 13:21           ` Luca Boccassi
2019-04-04 12:52     ` Ray Kinsella
2019-04-04 12:52       ` Ray Kinsella
2019-04-04 14:07       ` Burakov, Anatoly
2019-04-04 14:07         ` Burakov, Anatoly
2019-04-07  9:48         ` Thomas Monjalon
2019-04-07  9:48           ` Thomas Monjalon
2019-04-08  9:04           ` Ray Kinsella
2019-04-08  9:04             ` Ray Kinsella
2019-04-08 10:15             ` Burakov, Anatoly
2019-04-08 10:15               ` Burakov, Anatoly
2019-04-08 13:00               ` Ray Kinsella
2019-04-08 13:00                 ` Ray Kinsella
2019-04-08 13:38                 ` Burakov, Anatoly [this message]
2019-04-08 13:38                   ` Burakov, Anatoly
2019-04-08 13:58                   ` David Marchand
2019-04-08 13:58                     ` David Marchand
2019-04-08 14:02                     ` Burakov, Anatoly
2019-04-08 14:02                       ` Burakov, Anatoly
2019-04-08 14:38                       ` David Marchand
2019-04-08 14:38                         ` David Marchand
2019-04-08 15:13                         ` Stephen Hemminger
2019-04-08 15:13                           ` Stephen Hemminger
2019-04-08 15:49                         ` Burakov, Anatoly
2019-04-08 15:49                           ` Burakov, Anatoly
2019-04-10  8:35                           ` David Marchand
2019-04-10  8:35                             ` David Marchand
2019-04-08 15:50                         ` Burakov, Anatoly
2019-04-08 15:50                           ` Burakov, Anatoly
2019-04-09  9:42                   ` Ray Kinsella
2019-04-09  9:42                     ` Ray Kinsella
2019-04-14  0:42             ` Neil Horman
2019-04-14  0:42               ` Neil Horman
2019-04-15  9:10               ` Bruce Richardson
2019-04-15  9:10                 ` Bruce Richardson
2019-04-04 15:51     ` Stephen Hemminger
2019-04-04 15:51       ` Stephen Hemminger
2019-04-04 16:37       ` Burakov, Anatoly
2019-04-04 16:37         ` Burakov, Anatoly
2019-04-04 16:56     ` Kevin Traynor
2019-04-04 16:56       ` Kevin Traynor
2019-04-04 19:08       ` Wiles, Keith
2019-04-04 19:08         ` Wiles, Keith
2019-04-04 20:13         ` Kevin Traynor
2019-04-04 20:13           ` Kevin Traynor
2019-04-05 13:30           ` Ray Kinsella
2019-04-05 13:30             ` Ray Kinsella
2019-04-05 13:29         ` Ray Kinsella
2019-04-05 13:29           ` Ray Kinsella
2019-04-04  9:47 ` [dpdk-dev] " Kevin Traynor
2019-04-04  9:47   ` Kevin Traynor
2019-04-04 13:16   ` Ray Kinsella
2019-04-04 13:16     ` Ray Kinsella
2019-04-10  5:14 ` Honnappa Nagarahalli
2019-04-10  5:14   ` Honnappa Nagarahalli
2019-04-10  9:03   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10  9:03     ` Bruce Richardson
2019-04-10  9:43   ` [dpdk-dev] " Luca Boccassi
2019-04-10  9:43     ` Luca Boccassi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a9bf695-b287-9e5e-358c-d6c3f93db045@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ktraynor@redhat.com \
    --cc=mdr@ashroe.eu \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).