> -----Original Message----- > From: Ray Kinsella <m...@ashroe.eu> > Sent: Tuesday, April 23, 2019 7:54 PM > To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Stephen Hemminger > <step...@networkplumber.org> > Cc: Bruce Richardson <bruce.richard...@intel.com>; Honnappa Nagarahalli > <honnappa.nagaraha...@arm.com>; dev@dpdk.org; Ananyev, Konstantin > <konstantin.anan...@intel.com>; tho...@monjalon.net; nd <n...@arm.com> > Subject: Re: [EXT] Re: [dpdk-dev] ABI and inline functions > > > > On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote: > > > >> -----Original Message----- > >> From: Stephen Hemminger <step...@networkplumber.org> > >> Sent: Thursday, April 18, 2019 12:21 AM > >> To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > >> Cc: Bruce Richardson <bruce.richard...@intel.com>; Honnappa > >> Nagarahalli <honnappa.nagaraha...@arm.com>; dev@dpdk.org; Ananyev, > >> Konstantin <konstantin.anan...@intel.com>; tho...@monjalon.net; Ray > >> Kinsella <m...@ashroe.eu>; nd <n...@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). > > So is there a real versus a perceived compromise happen here - that we are > compromising optimal performance in order to make API stability happen? Do > we have specific an examples that this is actually the case?
The arm64 integrated SoC would functions as PCIE EP mode as well. That would means that you will have x86/arm64 server machine and Integrated NIC controller SoC connected to server over PCIE. The usecase for this to have packet processing offload from server to EP device to save server cycles. Where EP device will be treated as FW and internally it runs DPDK as HW Abstraction library for FW. > > Thanks, > > Ray K >
