[dpdk-dev] [RFC] ring: make ring implementation non-inlined

[Honnappa Nagarahalli]

<snip>

> Subject: Re: [dpdk-dev] [RFC] ring: make ring implementation non-inlined
> 
> 26/03/2020 09:04, Morten Brørup:
> > From: Jerin Jacob
> > > On Fri, Mar 20, 2020 Konstantin Ananyev wrote:
> > > >
> > > > As was discussed here:
> > > > http://mails.dpdk.org/archives/dev/2020-February/158586.html
> > > > this RFC aimed to hide ring internals into .c and make all ring
> > > > functions non-inlined. In theory that might help to maintain ABI
> > > > stability in future.
> > > > This is just a POC to measure the impact of proposed idea, proper
> > > > implementation would definetly need some extra effort.
> > > > On IA box (SKX) ring_perf_autotest shows ~20-30 cycles extra for
> > > > enqueue+dequeue pair. On some more realistic code, I suspect
> > > > the impact it might be a bit higher.
> > > > For MP/MC bulk transfers degradation seems quite small, though for
> > > > SP/SC and/or small transfers it is more then noticable (see exact
> > > > numbers below).
> > > > From my perspective we'd probably keep it inlined for now to avoid
> > > > any non-anticipated perfomance degradations.
> > > > Though intersted to see perf results and opinions from other
> > > > interested parties.
> > >
> > > +1
> 
> Konstantin, thank you for doing some measures
> 
> 
> > > My reasoning is a bit different, DPDK is using in embedded boxes too
> > > where performance has more weight than ABI stuff.
> >
> > As a network appliance vendor I can confirm that we certainly care
> > more about performance than ABI stability.
> > ABI stability is irrelevant for us;
> > and API instability is a non-recurring engineering cost each time we
> > choose to switch to a new DPDK version, which we only do if we cannot
> > avoid it, e.g. due to new drivers, security fixes or new features that
> > we want to use.
> >
> > For us, the trend pointed in the wrong direction when DPDK switched
> > the preference towards runtime configurability and deprecated compile
> > time configurability. I do understand the reasoning behind it, and the
> > impact is minimal, so we accept it.
> 
> The code can be optimized by removing some instructions with #ifdef.
> But the complexity of managing #ifdef enabling/disabling, depending on the
> platform and the use case, would be huge.
> We try to have a reasonable code "always enabled" which performs well in all
> cases. This is a design choice which makes DPDK a library, not a pool of code
> to cherry-pick.
> 
> > However, if DPDK starts sacrificing performance of the core libraries
> > for the benefits of the GNU/Linux distributors, network appliance
> > vendors may put more effort into sticking with old DPDK versions
> > instead of updating.
> 
> The initial choice regarding ABI compatibility was "do not care".
> Recently, the decision was done to care about ABI compatibility as priority
> number 2. The priority number 1 remains the performance.
> That's a reason for allowing some ABI breakages in some specific releases
> announced in advance.
> 
> > > I think we need to focus first on slow path APIs ABI stuff.
> 
> Yes we should not degrade fast path performance for the sake of avoiding
> uncertain future ABI issues.
> 
> Morten, Jerin, thank you for the feedback.
I think we have a consensus here not to make any changes to inline functions for now.
Should we mark this as 'Deferred or Rejected'?

>