[dpdk-dev] [EXT] Re: ABI and inline functions

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Thursday, April 18, 2019 12:21 AM
> To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>
> Cc: Bruce Richardson <bruce.richardson at intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli at arm.com>; dev at dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>; thomas at monjalon.net; Ray Kinsella
> <mdr at ashroe.eu>; nd <nd at arm.com>
> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> > 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.
> 
> Nobody cares about compatiablity until they have to the first security update.

For fixed appliance case, The update(FW update) will be  a single blob which
Include all the components. So they can back port the security fix and recompile
the sw as needed.

The very similar category  is DPDK running in smart NICs(Runs as FW in PCIe EP device).



>