I haven't performance tested, but they are compiler branch prediction hints pointing out the most likely execution path, so I expect them to have a positive effect.
E.g. the first comparison in __rte_pktmbuf_read() is very unlikely to be true - it would mean that the application is trying to read data beyond the packet. Please also refer to: https://cellperformance.beyond3d.com/articles/2006/04/branch-patterns-using-gcc.html > -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Honnappa Nagarahalli > Sent: Monday, July 23, 2018 7:52 PM > To: Morten Brørup; Olivier Matz > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] rte_mbuf library likely()/unlikely() > > Do you see any performance improvements with these changes? > > -----Original Message----- > From: dev <dev-boun...@dpdk.org> On Behalf Of Morten Brørup > Sent: Monday, July 23, 2018 8:54 AM > To: Olivier Matz <olivier.m...@6wind.com> > Cc: dev@dpdk.org > Subject: [dpdk-dev] rte_mbuf library likely()/unlikely() > > Hi Olivier, > > > > I noticed that __rte_pktmbuf_read() could do with an unlikely(), so I went > through the entire library. Here are my suggested modifications. >
