> -----Original Message----- > From: dev <dev-boun...@dpdk.org> On Behalf Of Bruce Richardson > Sent: Wednesday, April 17, 2019 2:07 PM > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Cc: dev@dpdk.org; Stephen Hemminger <step...@networkplumber.org>; > Ananyev, Konstantin <konstantin.anan...@intel.com>; tho...@monjalon.net; > Ray Kinsella <m...@ashroe.eu>; nd <n...@arm.com> > Subject: Re: [dpdk-dev] ABI and inline functions > > > 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 > > Agree with this. Anything not data path should not be inline. The next > question > then is for data path items how to determine whether they need to be inline or > not. In general my rule-of-thumb: > * anything dealing with bursts of packets should not be inline
# I think, we need consider the how fat is the function too, If it is light weight, probably we need to make it inline # Except the forward case, In real world use case, it is not trivial make large burst of packet to process it even though function prototype burst. We may need to consider that # For the given function if some argument is used with inline other function, probably no point in making that function alone inline as the structure is exposed in some other function. > * anything what works with single packet at a time should be inline > > > 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. > > > I would value ABI compatibility much higher than API compatibility. If someone > is recompiling the application anyway, making a couple of small changes (large > rework is obviously a different issue) to the code should not be a massive > issue, I > hope. On the other hand, ABI compatibility is needed to allow seamless update > from one version to another, and it's that ABI compatiblity that allows > distro's to > pick up our latest and greatest versions. IMO, We have two primary use case for DPDK 1) NFV kind of use case where the application needs to run on multiple platform without recompiling it. 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated Controller used. For fixed appliance use case, end user care more of performance than ABI compatibility as it easy to recompile the end user application vs the cost of hitting performance impact. IMO, DPDK needs to cater to both category. My 2c. > > Personally, I'd be happy enough to allow API changes at any point without > deprecation notice, so long as function versioning is used to ensure ABI > compatibility is kept. > > My 2c. > /Bruce
