>
> Note:
> a) the memarea is oriented towards the application layer, which could
> provides 'region-based memory management' [1] function.
>
Judging from the API, this library would rather provide
an interface to a generic allocator over a fixed memory extent,
because it offers freeing of specific elements, and thus must track them.
So it's more than RBMM. Is this intended?
It's a very interesting RFC anyway, just trying to understand the scope.
b) the eal library also provide memory zone/heap management, but these
> are tied to huge pages management.
>
[...]
> + * The memarea is a collection of allocated objects that can be
> efficiently
> + * alloc or free all at once, the main feature are as follows:
> + * a) it facilitate alloc and free of memory with low overhead.
> + * [...]
>
+ * c) it supports MT-safe as long as it's specified at creation time.
>
These two bullets seem to add the most value compared to DPDK heap API.
DPDK heap overhead is at least 64 bytes per allocation (sizeof malloc_elem),
so I assume memarea aims at a large number of small elements.
> +struct rte_memarea_param {
> + char name[RTE_MEMAREA_NAMESIZE]; /**< Name of memarea */
> + enum rte_memarea_source source; /**< Memory source of memarea */
> + uint64_t size; /**< Size (byte) of memarea */
>
Is it an upper limit or a guaranteed size?
It probably depends on the source: guaranteed for USER_ADDR,
upper limit for SYSAPI (or it would be no different from USER_ADDR),
not sure about USER_MEMAREA.
Do you envision memarea as always limited?
Generic allocators usually have means of adding extents,
even if this one doesn't currently.
Nit: size is uint64_t here but uint32_t in rte_memarea_allloc().
Should be size_t in both places.
> + uint32_t align; /**< Align of allocated object */
>
+ /** Indicates whether the memarea should be MT-safe */
> + bool mt_safe;
> + /** Indicates whether the memarea is visible to multiple process.
> + * If the memory source is RTE_MEMAREA_SOURCE_USER_ADDR, this filed
> + * depends on user settings and must be set.
> + * If the memory source is RTE_MEMAREA_SOURCE_SYSAPI or
> + * RTE_MEMAREA_SOURCE_USER_MEMAREA, this filed does not need to be
> set.
> + */
> + bool mp_visible;
> + /** User provided address, this field is valid only when source
> + * is set to RTE_MEMAREA_SOURCE_USER_ADDR.
> + */
> + void *user_addr;
> + /** User provided memarea, this field is valid only when source
> + * is set to RTE_MEMAREA_SOURCE_MEMAREA.
> + */
> + struct rte_memarea *user_memarea;
>
Jerin already suggested a union here.
I'll add another reason to do so: if in the future there will be new
memarea types
that require new options, one pointer-sized field can be used to pass
anything
without breaking the ABI once this structure becomes stable.
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Update memory's refcnt.
> + *
> + * Update one memory region's refcnt.
> + *
> + * @param ma
> + * The pointer of memarea.
> + * @param ptr
> + * The pointer of memory region which need be updated refcnt.
> + * @param value
> + * The value which need be updated.
> + * Note: it could be negative.
> + *
> + * @return
> + * 0 on success. Otherwise negative value is returned.
> + */
> +__rte_experimental
> +int rte_memarea_refcnt_update(struct rte_memarea *ma, void *ptr, int16_t
> value);
>
If this function only updates the refcnt, an API to inspect the refcnt is
missing.
Furthermore, in this case refcnt is just a value attached to every object,
what is the benefit compared to simply storing it in the object?
If this function also frees "ptr" when refcnt reaches zero,
missing is a way for the user to know that it did.
What happens if refcnt > 1 on rte_memarea_free()?
I don't think refcnt belongs to this library.
A principal objection: memarea is for freeing all objects at once,
refcnt is for releasing objects one-by-one when they're not used.
Technical issues I foresee: refcnt can be atomic (and require alignment) or
not,
16 bits may be too few (rte_flow_action_handle ref'd by thousands of
rte_flow).
Refcnt could be optional per memarea, but it seems like another
complication.
