Re: [dpdk-dev] ABI and inline functions

[Jerin Jacob Kollanukkaran <jerinj@marvell.com>]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Wednesday, April 17, 2019 2:07 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> Ray Kinsella <mdr@ashroe.eu>; nd <nd@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