[PATCH 0/3] Defer lcore variables allocation

[Mattias Rönnblom]

On 2024-12-16 10:49, David Marchand wrote:
> On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly
> <anatoly.burakov at 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().
> 
> 

After rte_eal_cleanup() is called, no DPDK calls may be made.

So, with the current API, there is no such use case to break.