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