From: "Richardson, Bruce" <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-announce] important design choices - statistics - ABI
Date: Wed, 17 Jun 2015 11:06:42 +0000 [thread overview]
Message-ID: <59AF69C657FD0841A61C55336867B5B034558F92@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <20150617103521.GB24677@hmsreliant.think-freely.org>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> Sent: Wednesday, June 17, 2015 11:35 AM
> To: Thomas Monjalon
> Cc: announce@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-announce] important design choices -
> statistics - ABI
>
> On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
> > Hi all,
> >
> > Sometimes there are some important discussions about architecture or
> > design which require opinions from several developers. Unfortunately,
> > we cannot read every threads. Maybe that using the announce mailing
> > list will help to bring more audience to these discussions.
> > Please note that
> > - the announce@ ML is moderated to keep a low traffic,
> > - every announce email is forwarded to dev@ ML.
> > In case you want to reply to this email, please use dev@dpdk.org
> address.
> >
> > There were some debates about software statistics disabling.
> > Should they be always on or possibly disabled when compiled?
> > We need to take a decision shortly and discuss (or agree) this proposal:
> > http://dpdk.org/ml/archives/dev/2015-June/019461.html
> >
> > During the development of the release 2.0, there was an agreement to
> > keep ABI compatibility or to bring new ABI while keeping old one during
> one release.
> > In case it's not possible to have this transition, the (exceptional)
> > break should be acknowledged by several developers.
> > http://dpdk.org/doc/guides-2.0/rel_notes/abi.html
> > There were some interesting discussions but not a lot of participants:
> >
> > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=84
> > 61
> >
> > During the current development cycle for the release 2.1, the ABI
> > question arises many times in different threads.
> > To add the hash key size field, it is proposed to use a struct padding
> gap:
> > http://dpdk.org/ml/archives/dev/2015-June/019386.html
> > To support the flow director for VF, there is no proposal yet:
> > http://dpdk.org/ml/archives/dev/2015-June/019343.html
> > To add the speed capability, it is proposed to break ABI in the release
> 2.2:
> > http://dpdk.org/ml/archives/dev/2015-June/019225.html
> > To support vhost-user multiqueues, it is proposed to break ABI in 2.2:
> > http://dpdk.org/ml/archives/dev/2015-June/019443.html
> > To add the interrupt mode, it is proposed to add a build-time option
> > CONFIG_RTE_EAL_RX_INTR to switch between compatible and ABI breaking
> binary:
> > http://dpdk.org/ml/archives/dev/2015-June/018947.html
> > To add the packet type, there is a proposal to add a build-time option
> > CONFIG_RTE_NEXT_ABI common to every ABI breaking features:
> > http://dpdk.org/ml/archives/dev/2015-June/019172.html
> > We must also better document how to remove a deprecated ABI:
> > http://dpdk.org/ml/archives/dev/2015-June/019465.html
> > The ABI compatibility is a new constraint and we need to better
> > understand what it means and how to proceed. Even the macros are not yet
> well documented:
> > http://dpdk.org/ml/archives/dev/2015-June/019357.html
> >
> > Thanks for your attention and your participation in these important
> choices.
> >
>
> Thomas-
> Just to re-iterate what you said earlier, and what was discussed in
> the previous ABI discussions
>
> 1) ABI stability was introduced to promote DPDK's ability to be included
> with various linux and BSD distributions. Distributions, by and large,
> favor building libraries as DSO's, favoring security and updatability in
> favor of all out performance.
>
> 2) The desire was to put DPDK developers in a mindset whereby ABI
> stability was something they needed to think about during development, as
> the DPDK exposes many data structures and instances that cannot be changed
> without breaking ABI
>
> 3) The versioning mechanism was introduced to allow for backward
> compatibility during periods in which we needed to support both an old an
> new ABI
>
> 4) As Stephan and others point out, its not expected that we will always
> be able to maintain ABI, and as such an easy library versioning mechanism
> was introduced to prevent the loading of an incompatible library with an
> older application
>
> 5) The ABI policy was introduced to create a method by which new ABI
> facets could be scheduled while allowing distros to prepare their
> downstream users for the upcomming changes.
>
>
> It seems to me, looking back over these last few months, that we're
> falling down a bit on our use of (3). I've seen several people take
> advantage of the ABI scheduled updates, but no one has tried the
> versioning interface, and as a result patches are getting delayed, which
> was never my intent. Not sure whats to be done about that, but we should
> probably address it. Is use of the versionnig interface just too hard or
> convoluted?
>
> Neil
Hi Neil,
on my end, some suggestions:
1. the documentation on changing an API function provided in rte_compat.h
is really good, but I don't think this is present in our documentation in
the docs folder or on website is it (apologies if it is and I've missed
it)? This needs to go into programmers guide or some other doc (perhaps
the new doc that the coding style went into).
2. The documentation also needs an example of: this is how you add a new
function and update the map file, and this is how you a) mark a function
as deprecated and b) remove it completely. That way we could have one
guide covering API versioning, how to add, modify and remove functions.
3. This doc should also cover how to use the API checker tool, something I
haven't had the chance to look at yet, but should do in the near future!
:-)
Regards,
/Bruce
next prev parent reply other threads:[~2015-06-17 11:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 23:29 [dpdk-announce] important design choices - statistics - ABI Thomas Monjalon
2015-06-17 4:36 ` Matthew Hall
2015-06-17 5:28 ` Stephen Hemminger
2015-06-17 8:23 ` Thomas Monjalon
2015-06-17 8:23 ` Marc Sune
2015-06-17 11:17 ` Bruce Richardson
2015-06-18 16:32 ` Dumitrescu, Cristian
2015-06-18 13:25 ` Dumitrescu, Cristian
2015-06-17 9:54 ` Morten Brørup
2015-06-18 13:00 ` Dumitrescu, Cristian
2015-06-17 10:35 ` Neil Horman
2015-06-17 11:06 ` Richardson, Bruce [this message]
2015-06-19 11:08 ` Mcnamara, John
2015-06-17 12:14 ` Panu Matilainen
2015-06-17 13:21 ` Vincent JARDIN
2015-06-18 8:36 ` Zhang, Helin
2015-06-18 16:55 ` O'Driscoll, Tim
2015-06-18 21:13 ` Vincent JARDIN
2015-06-19 10:26 ` Neil Horman
2015-06-19 12:32 ` Thomas Monjalon
2015-06-19 13:02 ` Neil Horman
2015-06-19 13:16 ` Thomas Monjalon
2015-06-19 15:27 ` Neil Horman
2015-06-19 15:51 ` Thomas Monjalon
2015-06-19 16:13 ` Thomas F Herbert
2015-06-19 17:02 ` Thomas Monjalon
2015-06-19 17:57 ` Thomas F Herbert
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=59AF69C657FD0841A61C55336867B5B034558F92@IRSMSX103.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
--cc=thomas.monjalon@6wind.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.