[dpdk-dev] ABI and inline functions

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

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)

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.
2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin

2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?

Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).

In this context, does it make sense to say that we will maintain API compatibility rather than saying ABI compatibility? This will also send the right message to the end users.


Thank you,
Honnappa

[1] http://mails.dpdk.org/archives/dev/2019-April/130151.html