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. > > > > 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 > >
