On 12/5/2024 6:57 PM, David Marchand wrote:
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications does not use DPDK, or use features associated to
some lcore variables.
While the amount has been reduced in a rush before rc2,
there are still cases when the increased memory footprint is noticed
like in scaling tests.
See https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2090931
lcore variable allocations in constructor is a bad idea, as the
application consuming DPDK has no control over such allocation:
linking some code does not mean that all of it will be used at runtime.
The general question on whether lcore variables in constructor should
be forbidden, is left to a later discussion.
For now, this series only focus on fixing subsystems using lcore
variables so that those allocations are deferred either in rte_eal_init()
or in the path that does require such lcore variables.
An idle question: would this have any consequences in use case of eal
init -> eal cleanup -> eal init with different arguments?
--
Thanks,
Anatoly
