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.