On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
<[email protected]> wrote:
>
> On 6/4/22 12:33, Jerin Jacob wrote:
> > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <[email protected]>
> > 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. 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
}
> 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
> >>
> >>
>
