DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: Luca Boccassi <bluca@debian.org>,
	Bruce Richardson <bruce.richardson@intel.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Kevin Traynor <ktraynor@redhat.com>,
	"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
Date: Thu, 4 Apr 2019 14:05:27 +0100	[thread overview]
Message-ID: <3055e4ce-767b-ab43-43ac-c3604fd3ea5c@ashroe.eu> (raw)
Message-ID: <20190404130527.CLHCmOX9hiLF1YcxK0TRu4cwueyh-ZwZgKBmEkMgoTA@z> (raw)
In-Reply-To: <4ec2c98004ef5d693d0e033c93820580bbd2ebfa.camel@debian.org>



On 04/04/2019 13:02, Luca Boccassi wrote:
> On Thu, 2019-04-04 at 11:54 +0100, 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]
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development
>> for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project -
>> it
>> should just start acting like it.
>>
>> Now, in terms of features like the memory rework, that is indeed a
>> case
>> that there was no alternative other than a massive ABI break.
>> However, for
>> that rework there was a strong need for improvement in that area that
>> we
>> can make the case for an ABI break to support it - and it is of a
>> scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are
>> of
>> that scale.
> 
> Fully agree.
> 
> It's normal for new project, big and small, to start without a
> stability promise as development ramps up, and then steer toward
> stability as the user base grows. Sometimes the switch is made explicit
> by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> I don't think we crossed that boundary yet in this project, and I
> believe that's the main question Ray was trying to raise: has the time
> finally come for DPDK to do this phase shift?

Yes - we never had a 1.0, where we cut an API and stood behind it
similar to GStreamer. There a number of reasons why this happened not
worth going into, however you make the point very well Luca - this phase
shift is long over due.

> 
> Of course it comes with a price for all developers, and that's again
> common.

Agreed - nothing is for free.
The question is this something we value and is it something worth doing.

> 
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should
>> reduce
>> the scope for ABI breaks.
> 
> Yes, I'm a big fan of accessors and opaque structs.

+1, me too.

> 
>> 2. Once done, I think we should commit to having an ABI break only in
>> the
>> rarest of circumstances, and only with very large justification. I
>> want us
>> to get to the point where DPDK releases can immediately be picked up
>> by all
>> linux distros and rolled out because they are ABI compatible.
>>
>> I'm not sure I like the idea of planned ABI break releases - that
>> strikes
>> me as a plan where we end up with the same number of ABI breaks as
>> before,
>> just balled into one release.
> 
> I think that was intended as a compromise, especially as we move from
> one model to the other, and more of a "if a breakage has to happen, it
> must be in the X release" rather than "let's always break in the X
> release" :-)
> 
>> Question for Kevin, Luca and others who look at distro-packaging: is
>> it the
>> case that each distro will only ship one version of DPDK, or is it
>> possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
> 
> We can ship multiple versions, although it's more work so there should
> be a good reason to do it. 

Well you already kind of do right.
You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9 backports.

> At the moment in Debian and Ubuntu we don't,
> and we tend to ship whatever the latest LTS version is at the distro
> freeze milestone - for example Debian 10 which will be released soon
> (TM) will have 18.11.0.

Presumably when 19.11 arrives, it will land in Debian 10 backports
similarly.

I assume anything that lands in backports is not guaranteed to be ABI
compatible with stable?

> 
>> So, in short, I'm generally in favour of a zero-tolerance approach
>> for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory
>> layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>

  parent reply	other threads:[~2019-04-04 13:05 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 [this message]
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
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=3055e4ce-767b-ab43-43ac-c3604fd3ea5c@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=anatoly.burakov@intel.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ktraynor@redhat.com \
    --cc=techboard@dpdk.org \
    /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).