> From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> Sent: Saturday, 4 June 2022 13.10
>
> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> <andrew.rybche...@oktetlabs.ru> wrote:
> >
> > On 6/4/22 12:33, Jerin Jacob wrote:
> > > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> <m...@smartsharesystems.com> wrote:
> > >>
> > >> I would like the DPDK community to change its view on compile time
> options. Here is why:
> > >>
> > >>
> > >>
> > >> Application specific performance micro-optimizations like “fast
> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> presented as features.
> > >>
> > >>
> > >>
> > >> They are not features, but optimizations, and I don’t understand
> the need for them to be available at run-time!
> > >>
> > >>
> > >>
> > >> Instead of adding a bunch of exotic exceptions to the fast path of
> the PMDs, they should be compile time options. This will improve
> performance by avoiding branches in the fast path, both for the
> applications using them, and for generic applications (where the exotic
> code is omitted).
> > >
> > > Agree. I think, keeping the best of both worlds would be
> > >
> > > -Enable the feature/optimization as runtime
> > > -Have a compile-time option to disable the feature/optimization as
> an override.
> >
> > It is hard to find the right balance, but in general compile
> > time options are a nightmare for maintenance. Number of
> > required builds will grow as an exponent.
Test combinations are exponential for N features, regardless if N are runtime
or compile time options.
> > Of course, we can
> > limit number of checked combinations, but it will result in
> > flow of patches to fix build in other cases.
>
> The build breakage can be fixed if we use (2) vs (1)
>
> 1)
> #ifdef ...
> My feature
> #endif
>
> 2)
> static __rte_always_inline int
> rte_has_xyz_feature(void)
> {
> #ifdef RTE_LIBRTE_XYZ_FEATURE
> return RTE_LIBRTE_XYZ_FEATURE;
> #else
> return 0;
> #endif
> }
>
> if(rte_has_xyz_feature())) {
> My feature code
>
> }
>
I'm not sure all the features can be covered by that, e.g. added fields in
structures.
Also, I would consider such features "opt in" at compile time only. As such,
they could be allowed to break the ABI/API.
>
>
> > Also compile time options tend to make code less readable
> > which makes all aspects of the development harder.
> >
> > Yes, compile time is nice for micro optimizations, but
> > I have great concerns that it is a right way to go.
> >
> > >> Please note that I am only talking about the performance
> optimizations that are limited to application specific use cases. I
> think it makes sense to require that performance optimizing an
> application also requires recompiling the performance critical
> libraries used by it.
> > >>
> > >>
> > >>
> > >> Allowing compile time options for application specific performance
> optimizations in DPDK would also open a path for other optimizations,
> which can only be achieved at compile time, such as “no fragmented
> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> exotic optimizations, such as the “indexed mempool cache”, which was
> rejected due to ABI violations – they could be marked as “risky and
> untested” or similar, but still be part of the DPDK main repository.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Med venlig hilsen / Kind regards,
> > >>
> > >> -Morten Brørup
> > >>
> > >>
> >
