On 2024-12-16 10:49, David Marchand wrote:
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().
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.
