Re: [dpdk-dev] [RFC PATCH 0/2] dynamic memzones

[Olivier MATZ <olivier.matz@6wind.com>]

Hi Sergio,

On 05/08/2015 06:37 PM, Sergio Gonzalez Monroy wrote:
> Please NOTE that this series is meant to illustrate an idea/approach and start
> discussion on the topic.
>
> Current implemetation allows reserving/creating memzones but not the opposite
> (unreserve/delete). This affects mempools and other memzone based objects.
>
>  From my point of view, implementing unreserve functionality for memzones would
> look like malloc over memsegs.
> Thus, this approach moves malloc inside eal (which in turn removes a circular
> dependency), where malloc heaps are composed of memsegs.
> We keep both malloc and memzone APIs as they are, but memzones allocate its
> memory by calling malloc_heap_alloc (there would be some ABI changes, see below).
> Some extra functionality is required in malloc to allow for boundary constrained
> memory requests.
> In summary, currently malloc is based on memzones, and with this approach
> memzones are based on malloc.
>
> An alternative would be to move malloc internals (malloc_heap, malloc_elem)
> to the eal, but keeping the malloc library as is, where malloc is based on
> memzones. This way we could avoid ABI changes while keeping the existing
> circular dependency between malloc and eal.
>
> TODOs:
>   - Implement memzone_unreserve, simply call rte_malloc_free.
>   - Implement mempool_delete, simply call rte_memzone_unreserve.
>   - Init heaps with all available memsegs at once.
>   - Review symbols in version map.
>
> ABI changes:
>   - Removed support for rte_memzone_reserve_xxxx with len=0 (not needed?).
>   - Removed librte_malloc as single library (linker script as work around?).
>
> IDEAS FOR FUTURE WORK:
>   - More control over requested memory, ie. shared/private, phys_contig, etc.
>     One of the goals would be trying to reduce the need of physically contiguous
>     memory when not required.
>   - Attach/unattach hugepages at runtime (faster VM migration).
>   - Improve malloc algorithm? ie. jemalloc (or any other).
>
>
> Any comments/toughts and/or different approaches are welcome.

I like the idea and I don't see any issue on the principle. It
will clearly help to have dynamic pools or rings.

(I didn't dive in the second patch very deep, it's just a
high-level thought).

Regards,
Olivier