On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly <anatoly.bura...@intel.com> wrote: > > 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?
Hum, interesting question. I would say that initialising lcore variables in constructors means that this usecase is broken, since lcore variables are freed in eal_lcore_var_cleanup(). -- David Marchand
