[dpdk-dev] ABI and inline functions

[Burakov, Anatoly]

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