RE: [PATCH v11 1/7] eal: add static per-lcore memory allocation facility

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
> Sent: Tuesday, 15 October 2024 08.42
> 
> On 2024-10-14 10:17, Morten Brørup wrote:
> >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
> >> Sent: Monday, 14 October 2024 09.44
> >
> >
> >> +struct lcore_var_buffer {
> >> +	char data[RTE_MAX_LCORE_VAR * RTE_MAX_LCORE];
> >> +	struct lcore_var_buffer *prev;
> >> +};
> >
> > In relation to Jerin's request for using hugepages when available,
> the "data" field should be a pointer to the memory allocated from
> either the heap or through rte_malloc. You would also need to add a
> flag to indicate which it is, so the correct deallocation function can
> be used to free it on cleanup.
> >
> 
> The typing (glibc heap or DPDK heap) could be in the buffers
> themselves, no?

Yes, it would be a flag in the lcore_var_buffer structure.

Also, lcore_var_alloc() would use aligned_alloc() for allocating the "data" memory, not for allocating the lcore_var_buffer structure.

> 
> > <feature creep>
> > Here's another (nice to have) idea, which does not need to be part of
> this series, but can be implemented in a separate patch:
> > If you move "offset" into this structure, new lcore variables can be
> allocated from any buffer, instead of only the most recently allocated
> buffer.
> > There might even be gains by picking the "optimal" buffer to allocate
> different size variables from.
> > </feature creep>
> >
> 
> If the max lcore variable size is much greater than the actual variable
> sizes, the amount of fragmentation (i.e., the space at the end) will be
> very small.

Agree; the current design parameters uses a very large RTE_MAX_LCORE_VAR, so fragmentation should be negligible.
It may become relevant if using a smaller RTE_MAX_LCORE_VAR and many lcore_var_buffers are allocated.


> I don't think we should use huge pages for this facility, since they
> don't support demand paging.

I understand your reasoning; the RAM consumption will be huge.

I am not going to insist.
If someone really needs it, they can provide a separate patch in the future, preferably with a build time option in rte_config.h to enable/disable it.

> 
> The day we have a DPDK heap which support lcore-affinitized
> allocations,
> then potentially eal_common_lcore_var.c could use that, provided it's
> available (and there is a proper way to check [or get notified] if it
> is
> available or not).