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. Of course, we can
limit number of checked combinations, but it will result in
flow of patches to fix build in other cases.
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
