Hi Anatoly, On Wed, Mar 7, 2018 at 10:26 PM, Anatoly Burakov <anatoly.bura...@intel.com> wrote: > This patchset introduces dynamic memory allocation for DPDK (aka memory > hotplug). Based upon RFC submitted in December [1]. > > Dependencies (to be applied in specified order): > - IPC bugfixes patchset [2] > - IPC improvements patchset [3] > - IPC asynchronous request API patch [4] > - Function to return number of sockets [5] > > Deprecation notices relevant to this patchset: > - General outline of memory hotplug changes [6] > - EAL NUMA node count changes [7] > > The vast majority of changes are in the EAL and malloc, the external API > disruption is minimal: a new set of API's are added for contiguous memory > allocation for rte_memzone, and a few API additions in rte_memory due to > switch to memseg_lists as opposed to memsegs. Every other API change is > internal to EAL, and all of the memory allocation/freeing is handled > through rte_malloc, with no externally visible API changes. > > Quick outline of all changes done as part of this patchset: > > * Malloc heap adjusted to handle holes in address space > * Single memseg list replaced by multiple memseg lists > * VA space for hugepages is preallocated in advance > * Added alloc/free for pages happening as needed on rte_malloc/rte_free > * Added contiguous memory allocation API's for rte_memzone > * Integrated Pawel Wodkowski's patch for registering/unregistering memory > with VFIO [8] > * Callbacks for registering memory allocations > * Multiprocess support done via DPDK IPC introduced in 18.02 > > The biggest difference is a "memseg" now represents a single page (as opposed > to > being a big contiguous block of pages). As a consequence, both memzones and > malloc elements are no longer guaranteed to be physically contiguous, unless > the user asks for it at reserve time. To preserve whatever functionality that > was dependent on previous behavior, a legacy memory option is also provided, > however it is expected (or perhaps vainly hoped) to be temporary solution. > > Why multiple memseg lists instead of one? Since memseg is a single page now, > the list of memsegs will get quite big, and we need to locate pages somehow > when we allocate and free them. We could of course just walk the list and > allocate one contiguous chunk of VA space for memsegs, but this > implementation uses separate lists instead in order to speed up many > operations with memseg lists. > > For v1 and v2, the following limitations are present: > - FreeBSD does not even compile, let alone run > - No 32-bit support
I just read on annou...@dpdk.org [1] that an early merge to this series is expected. So, would this limitation be fixed before merge? Or, has it already been fixed in github repo? [1] http://dpdk.org/ml/archives/announce/2018-March/000182.html [...] - Shreyansh
