<snip> > > > Thanks Stephen. Do you see any performance difference with this change? > > > > > -----Original Message----- > > > From: Stephen Hemminger <step...@networkplumber.org> > > > Sent: Thursday, May 5, 2022 5:46 PM > > > To: dev@dpdk.org > > > Cc: Stephen Hemminger <step...@networkplumber.org> > > > Subject: [RFC] rte_ring: don't use always inline > > > > > > Forcing compiler to inline with always inline can lead to worse and > > > sometimes broken code. Better to use the standard inline keyword and > > > let compiler have some flexibilty. > > > > > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > > > --- > > > > > > This is RFC because the use of large scale inlining is debatable. > > > This change may slow things down on some versions of Gcc and > architectures. > > > > > > If you follow Linux kernel list, this has been a debated topic over > > > the years, with opinions for and against inlining. > > > Combined with bad inlining in various Gcc versions. > > > > > > lib/ring/rte_ring.h | 36 ++++++++++++++++++------------------ > > > lib/ring/rte_ring_c11_pvt.h | 6 +++--- > > > lib/ring/rte_ring_elem.h | 36 ++++++++++++++++++------------------ > > > 3 files changed, 39 insertions(+), 39 deletions(-) > > > <snip>
> > > > I have not run performance tests and don't have the infrastructure available > to > give a meaningful answer. The application we use doesn't make much use of > rings. > > This was more in response to the RISCV issues. The RISC-V issue is due to a compiler bug. Should we be making these changes due to a compiler bug in one architecture?
