Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> 
> 
> 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.
> 
I would be too, with certain exceptions - rte_mbuf for one. Any structures
that are used by applications cannot be made opaque, as apps do not want to
pay the cost of having to call a function every time they want to access
something from one of those structures.

Thankfully for us, we have plenty of other structures that we can work on
in the meantime that can be made private to avoid ABI breaks! :-) I suggest
we work through those first, allowing us to hone our ABI-break avoidance
skills.

/Bruce