On 2024-09-17 18:29, Konstantin Ananyev wrote:
+#define LCORE_BUFFER_SIZE (RTE_MAX_LCORE_VAR * RTE_MAX_LCORE)
+
+static void *lcore_buffer;
+static size_t offset = RTE_MAX_LCORE_VAR;
+
+static void *
+lcore_var_alloc(size_t size, size_t align)
+{
+ void *handle;
+ void *value;
+
+ offset = RTE_ALIGN_CEIL(offset, align);
+
+ if (offset + size > RTE_MAX_LCORE_VAR) {
+#ifdef RTE_EXEC_ENV_WINDOWS
+ lcore_buffer = _aligned_malloc(LCORE_BUFFER_SIZE,
+ RTE_CACHE_LINE_SIZE);
+#else
+ lcore_buffer = aligned_alloc(RTE_CACHE_LINE_SIZE,
+ LCORE_BUFFER_SIZE);
+#endif
Don't remember did that question already arise or not:
For debugging and health-checking purposes - would it make sense to link all
lcore_buffer values into a linked list?
So user/developer/some tool can walk over it to check that provided handle value
is really a valid lcore_var, etc.
At least you could add some basic statistics, like the total size
allocated my lcore variables, and the number of variables.
My thought was more about easing debugging/health-cheking,
but yes, some stats can also be collected.
Statistics could be used for debugging and maybe some kind of
rudimentary sanity check.
Maintaining per-variable state is not necessarily something you want to
do, at least not close (spatially) to the lcore variable values.
In summary, I'm yet to form an opinion what, if anything, we should have
here to help debugging. To avoid bloat, I would suggest this being
deferred up to a point where we have more experience with lcore variables.
One could also add tracing.
+ RTE_VERIFY(lcore_buffer != NULL);
+
+ offset = 0;
+ }
+
