On Fri, Mar 20, 2020 at 10:11 PM Konstantin Ananyev <konstantin.anan...@intel.com> 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 My reasoning is a bit different, DPDK is using in embedded boxes too where performance has more weight than ABI stuff. I think we need to focus first on slow path APIs ABI stuff. I spend a few cycles to apply this patch + http://mails.dpdk.org/archives/dev/2020-February/158586.html on top of the tree, there are a lot of conflicts. If I get a mergeable patch then I will test it on an arm64 box. > > Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz > ring_perf_autotest (without patch/with patch)
