DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Ray Kinsella <mdr@ashroe.eu>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] ABI and inline functions
Date: Wed, 24 Apr 2019 12:08:45 +0100	[thread overview]
Message-ID: <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> (raw)
Message-ID: <20190424110845.SnnzyF87jAV7T43uak7sF3nMJ-9iCbItoe16GFFVbJI@z> (raw)
In-Reply-To: <2ec4da50-d874-865a-6bcc-916ac676be39@ashroe.eu>

On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
> 
> 
> On 18/04/2019 11:28, Bruce Richardson wrote:
>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>
>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
>>>>> Hello,
>>>>> 	There was a conversation [1] in the context of RCU library. I thought
>>>>> it needs participation from broader audience. Summary for the context
>>>>> (please look at [1] for full details)
>>>>>
>>>>
>>>> Thanks for kicking off this discussion
>>>>
>>>>> 1) How do we provide ABI compatibility when the code base contains
>>>> inline functions? Unless we freeze development in these inline functions and
>>>> corresponding structures, it might not be possible to claim ABI compatibility.
>>>> Application has to be recompiled.
>>>>
>>>> I agree that in some cases the application "might" need to be recompiled,
>>>> but on the other hand I also think that there are many cases where ABI
>>>> function versioning can still be used to mitigate things. For example, if we
>>>> think of a couple of various scenarios:
>>>>
>>>> 1. If everything is inline and variables are allocated by app, e.g.
>>>> spinlock on stack, then there is no issue as everything is application
>>>> contained.
>>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>>
>>
>> If the application wants the bugfix, then yes. However, if the app is
>> unaffected by the bug, then it should have the option of updating DPDK
>> without a recompile.
> 
> I would also imagine that should be an extremely rare case, that a
> bugfix would require a structure change ... perhaps for an alignment issues?

Multiprocess threading issues is one case i've had to do that more than 
once.

<snip>


> 
> The reality is that most other system libraries provide strong
> guarantees ... to date we have provided very little.
> 

To our credit, the libraries you're likely referring to aren't trying to 
reimplement the Linux kernel :) I don't think we do these API/ABI breaks 
just because we like doing them - DPDK is complex, and getting 
everything right the first time *and* allowing for future evolution is 
not a trivial undertaking.

To me, part of the problem is that DPDK is an "everything and the 
kitchen sink" kind of library where there is a bunch of drivers, a whole 
quasi-OS layer of dealing with hardware in a cross-platform manner, a 
separate memory management system, a bunch of libraries such as hash/lpm 
tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a 
library" would concentrate on doing one thing well. DPDK, on the other 
hand, tries to do *everything* well. The sheer breadth of DPDK's scope 
is, i think, contributing to the breakages. If you keep 99% of your 
libraries stable between version, but there's a small ABI tweak in an 
LPM library, the entire DPDK stability gets invalidated.

Perhaps limiting DPDK's scope would help with this as well.

> 
>>
>> Regards,
>> /Bruce
>>
> 


-- 
Thanks,
Anatoly

  parent reply	other threads:[~2019-04-24 11:08 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17  5:12 Honnappa Nagarahalli
2019-04-17  5:12 ` Honnappa Nagarahalli
2019-04-17  8:36 ` Bruce Richardson
2019-04-17  8:36   ` Bruce Richardson
2019-04-17 16:52   ` Stephen Hemminger
2019-04-17 16:52     ` Stephen Hemminger
2019-04-17 17:46   ` Jerin Jacob Kollanukkaran
2019-04-17 17:46     ` Jerin Jacob Kollanukkaran
2019-04-17 18:51     ` Stephen Hemminger
2019-04-17 18:51       ` Stephen Hemminger
2019-04-18  5:56       ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-18  5:56         ` Jerin Jacob Kollanukkaran
2019-04-23 14:23         ` Ray Kinsella
2019-04-23 14:23           ` Ray Kinsella
2019-04-24 18:38           ` Jerin Jacob Kollanukkaran
2019-04-24 18:38             ` Jerin Jacob Kollanukkaran
2019-04-23 14:19       ` [dpdk-dev] " Ray Kinsella
2019-04-23 14:19         ` Ray Kinsella
2019-04-18  4:34   ` Honnappa Nagarahalli
2019-04-18  4:34     ` Honnappa Nagarahalli
2019-04-18 10:28     ` Bruce Richardson
2019-04-18 10:28       ` Bruce Richardson
2019-04-23 14:12       ` Ray Kinsella
2019-04-23 14:12         ` Ray Kinsella
2019-04-24  5:15         ` Honnappa Nagarahalli
2019-04-24  5:15           ` Honnappa Nagarahalli
2019-04-24 11:08         ` Burakov, Anatoly [this message]
2019-04-24 11:08           ` Burakov, Anatoly
2019-04-24 12:22           ` Ray Kinsella
2019-04-24 12:22             ` Ray Kinsella
2019-04-24 12:54             ` Burakov, Anatoly
2019-04-24 12:54               ` Burakov, Anatoly
2019-04-24 15:44               ` Stephen Hemminger
2019-04-24 15:44                 ` Stephen Hemminger
2019-04-30  8:52             ` Thomas Monjalon
2019-04-30  8:52               ` Thomas Monjalon
2019-04-24  5:08       ` Honnappa Nagarahalli
2019-04-24  5:08         ` Honnappa Nagarahalli
2019-04-24  8:49         ` Bruce Richardson
2019-04-24  8:49           ` Bruce Richardson

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=43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=nd@arm.com \
    --cc=stephen@networkplumber.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).