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
