DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: "Wiles, Keith" <keith.wiles@intel.com>,
	Kevin Traynor <ktraynor@redhat.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	dpdk-dev <dev@dpdk.org>,
	"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
Date: Fri, 5 Apr 2019 14:29:14 +0100	[thread overview]
Message-ID: <9ddde28c-241a-9a1b-ba57-416781472999@ashroe.eu> (raw)
Message-ID: <20190405132914.nLlEHEnAz3SQHt4n43ezXNeyYHI27G6cJtr7VYDxH84@z> (raw)
In-Reply-To: <B42554A2-232A-48E4-9A61-C234A577E415@intel.com>



On 04/04/2019 20:08, Wiles, Keith wrote:
> 
> 
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.

New APIs will be experimental in any case, as you say they are less of
problem.

I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.

Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.

>>
>>> 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.
>>>
>>> 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?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> 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
>>>
>>
> 
> Regards,
> Keith
> 

  parent reply	other threads:[~2019-04-05 13:29 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
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 [this message]
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=9ddde28c-241a-9a1b-ba57-416781472999@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=keith.wiles@intel.com \
    --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).