> From: Mattias Rönnblom [mailto:hof...@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.ronnb...@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).
