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
