Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On Saturday 03 March 2018 07:15 PM, Anatoly Burakov wrote: This patchset introduces dynamic memory allocation for DPDK (aka memory hotplug). Based upon RFC submitted in December [1]. Hi Anatoly, I am able to bring up pmd with these patches in powerpc. I am continuing to validate more on memory limits that this patch set has (eg pre-allocating anonymous mapping for largest mem possible as per default mem and memseg values). I'll keep posting my observations further. Thanks for the patches, Gowrishankar 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, the following limitations are present: - FreeBSD does not even compile, let alone run - No 32-bit support - There are some minor quality-of-life improvements planned that aren't ready yet and will be part of v2 - VFIO support is only smoke-tested (but is expected to work), VFIO support with secondary processes is not tested; work is ongoing to validate VFIO for all use cases - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR IOMMU mode - help from sPAPR maintainers requested Nevertheless, this patchset should be testable under 64-bit Linux, and should work for all use cases bar those mentioned above. [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ [6] http://dpdk.org/dev/patchwork/patch/34002/ [7] http://dpdk.org/dev/patchwork/patch/33853/ [8] http://dpdk.org/dev/patchwork/patch/24484/ Anatoly Burakov (41): eal: move get_virtual_area out of linuxapp eal_memory.c eal: move all locking to heap eal: make malloc heap a doubly-linked list eal: add function to dump malloc heap contents test: add command to dump malloc heap contents eal: make malloc_elem_join_adjacent_free public eal: make malloc free list remove public eal: make malloc free return resulting malloc element eal: add rte_fbarray eal: add "single file segments" command-line option eal: add "legacy memory" option eal: read hugepage counts from node-specific sysfs path eal: replace memseg with memseg lists eal: add support for mapping hugepages at runtime eal: add support for unmapping pages at runtime eal: make use of memory hotplug for init eal: enable memory hotplug support in rte_malloc test: fix malloc autotest to support memory hotplug eal: add API to check if memory is contiguous eal: add backend support for contiguous allocation eal: enable reserving physically contiguous memzones eal: replace memzone array with fbarray mempool: add support for the new allocation methods vfio: allow to map other memory regions eal: map
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 20-Mar-18 2:18 PM, Olivier Matz wrote: Hi, On Tue, Mar 20, 2018 at 01:51:31PM +, Burakov, Anatoly wrote: On 20-Mar-18 12:42 PM, Olivier Matz wrote: On Tue, Mar 20, 2018 at 10:27:55AM +, Burakov, Anatoly wrote: On 19-Mar-18 5:30 PM, Olivier Matz wrote: Hi Anatoly, On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: - FreeBSD does not even compile, let alone run - No 32-bit support - There are some minor quality-of-life improvements planned that aren't ready yet and will be part of v2 - VFIO support is only smoke-tested (but is expected to work), VFIO support with secondary processes is not tested; work is ongoing to validate VFIO for all use cases - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR IOMMU mode - help from sPAPR maintainers requested Nevertheless, this patchset should be testable under 64-bit Linux, and should work for all use cases bar those mentioned above. [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ [6] http://dpdk.org/dev/patchwork/patch/34002/ [7] http://dpdk.org/dev/patchwork/patch/33853/ [8] http://dpdk.org/dev/patchwork/patch/24484/ I did a quick pass on your patches (unfortunately, I don't have the time to really dive in it). I have few questions/comments: - This is really a big patchset. Thank you for working on this topic. I'll try to test our application with it as soon as possible. - I see from patch 17 that it is possible that rte_malloc() expands the heap by requesting more memory to the OS? Did I understand well? Today, a good property of rte_malloc() compared to malloc() is that it won't interrupt the process (the worst case is a spinlock). This is appreciable on a dataplane core. Will it change? Hi Olivier, Not sure what you mean by "interrupt the process". The new rte_malloc will _mostly_ work just like the old one. There are now two levels of locks: the heap lock, and the system allocation lock. If your rte_malloc call requests amount of memory that can be satisfied by already allocated memory, then only the heap lock is engaged - or, to put it in other words, things work as before. When you *don't* have enough memory allocated, previously rte_malloc would just fail. Now, it instead will lock the second lock and try to allocate more memory from the system. This requires IPC (
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
Hi, On Tue, Mar 20, 2018 at 01:51:31PM +, Burakov, Anatoly wrote: > On 20-Mar-18 12:42 PM, Olivier Matz wrote: > > On Tue, Mar 20, 2018 at 10:27:55AM +, Burakov, Anatoly wrote: > > > On 19-Mar-18 5:30 PM, Olivier Matz wrote: > > > > Hi Anatoly, > > > > > > > > On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: > > > > > - FreeBSD does not even compile, let alone run > > > > > - No 32-bit support > > > > > - There are some minor quality-of-life improvements planned that > > > > > aren't > > > > > ready yet and will be part of v2 > > > > > - VFIO support is only smoke-tested (but is expected to work), VFIO > > > > > support > > > > > with secondary processes is not tested; work is ongoing to > > > > > validate VFIO > > > > > for all use cases > > > > > - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR > > > > > IOMMU mode - help from sPAPR maintainers requested > > > > > > > > > > Nevertheless, this patchset should be testable under 64-bit Linux, and > > > > > should work for all use cases bar those mentioned above. > > > > > > > > > > [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ > > > > > [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ > > > > > [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ > > > > > [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ > > > > > [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ > > > > > [6] http://dpdk.org/dev/patchwork/patch/34002/ > > > > > [7] http://dpdk.org/dev/patchwork/patch/33853/ > > > > > [8] http://dpdk.org/dev/patchwork/patch/24484/ > > > > > > > > I did a quick pass on your patches (unfortunately, I don't have > > > > the time to really dive in it). > > > > > > > > I have few questions/comments: > > > > > > > > - This is really a big patchset. Thank you for working on this topic. > > > > I'll try to test our application with it as soon as possible. > > > > > > > > -
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 20-Mar-18 12:42 PM, Olivier Matz wrote: On Tue, Mar 20, 2018 at 10:27:55AM +, Burakov, Anatoly wrote: On 19-Mar-18 5:30 PM, Olivier Matz wrote: Hi Anatoly, On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: - FreeBSD does not even compile, let alone run - No 32-bit support - There are some minor quality-of-life improvements planned that aren't ready yet and will be part of v2 - VFIO support is only smoke-tested (but is expected to work), VFIO support with secondary processes is not tested; work is ongoing to validate VFIO for all use cases - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR IOMMU mode - help from sPAPR maintainers requested Nevertheless, this patchset should be testable under 64-bit Linux, and should work for all use cases bar those mentioned above. [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ [6] http://dpdk.org/dev/patchwork/patch/34002/ [7] http://dpdk.org/dev/patchwork/patch/33853/ [8] http://dpdk.org/dev/patchwork/patch/24484/ I did a quick pass on your patches (unfortunately, I don't have the time to really dive in it). I have few questions/comments: - This is really a big patchset. Thank you for working on this topic. I'll try to test our application with it as soon as possible. - I see from patch 17 that it is possible that rte_malloc() expands the heap by requesting more memory to the OS? Did I understand well? Today, a good property of rte_malloc() compared to malloc() is that it won't interrupt the process (the worst case is a spinlock). This is appreciable on a dataplane core. Will it change? Hi Olivier, Not sure what you mean by "interrupt the process". The new rte_malloc will _mostly_ work just like the old one. There are now two levels of locks: the heap lock, and the system allocation lock. If your rte_malloc call requests amount of memory that can be satisfied by already allocated memory, then only the heap lock is engaged - or, to put it in other words, things work as before. When you *don't* have enough memory allocated, previously rte_malloc would just fail. Now, it instead will lock the second lock and try to allocate more memory from the system. This requires IPC (to ensure all processes have allocated/freed the same memory), so this will take way longer (timeout is set to wait up to 5 seconds,
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On Tue, Mar 20, 2018 at 10:27:55AM +, Burakov, Anatoly wrote: > On 19-Mar-18 5:30 PM, Olivier Matz wrote: > > Hi Anatoly, > > > > On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: > > > - FreeBSD does not even compile, let alone run > > > - No 32-bit support > > > - There are some minor quality-of-life improvements planned that aren't > > >ready yet and will be part of v2 > > > - VFIO support is only smoke-tested (but is expected to work), VFIO > > > support > > >with secondary processes is not tested; work is ongoing to validate > > > VFIO > > >for all use cases > > > - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR > > >IOMMU mode - help from sPAPR maintainers requested > > > > > > Nevertheless, this patchset should be testable under 64-bit Linux, and > > > should work for all use cases bar those mentioned above. > > > > > > [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ > > > [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ > > > [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ > > > [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ > > > [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ > > > [6] http://dpdk.org/dev/patchwork/patch/34002/ > > > [7] http://dpdk.org/dev/patchwork/patch/33853/ > > > [8] http://dpdk.org/dev/patchwork/patch/24484/ > > > > I did a quick pass on your patches (unfortunately, I don't have > > the time to really dive in it). > > > > I have few questions/comments: > > > > - This is really a big patchset. Thank you for working on this topic. > >I'll try to test our application with it as soon as possible. > > > > - I see from patch 17 that it is possible that rte_malloc() expands > >the heap by requesting more memory to the OS? Did I understand well? > >Today, a good property of rte_malloc() compared to malloc() is that > >it won't interrupt the process (the worst case is a spinlock). This > >is appreciable on a dataplane core. Will it change? > > Hi Olivier, > > Not sure what you mean by "interrupt the process". The new rte_malloc will > _mostly_ work just like the old one. There are now two levels of locks: the > heap lock, and the system allocation lock. If your rte_malloc call reque
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 19-Mar-18 5:30 PM, Olivier Matz wrote: Hi Anatoly, On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: - FreeBSD does not even compile, let alone run - No 32-bit support - There are some minor quality-of-life improvements planned that aren't ready yet and will be part of v2 - VFIO support is only smoke-tested (but is expected to work), VFIO support with secondary processes is not tested; work is ongoing to validate VFIO for all use cases - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR IOMMU mode - help from sPAPR maintainers requested Nevertheless, this patchset should be testable under 64-bit Linux, and should work for all use cases bar those mentioned above. [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ [6] http://dpdk.org/dev/patchwork/patch/34002/ [7] http://dpdk.org/dev/patchwork/patch/33853/ [8] http://dpdk.org/dev/patchwork/patch/24484/ I did a quick pass on your patches (unfortunately, I don't have the time to really dive in it). I have few questions/comments: - This is really a big patchset. Thank you for working on this topic. I'll try to test our application with it as soon as possible. - I see from patch 17 that it is possible that rte_malloc() expands the heap by requesting more memory to the OS? Did I understand well? Today, a good property of rte_malloc() compared to malloc() is that it won't interrupt the process (the worst case is a spinlock). This is appreciable on a dataplane core. Will it change? Hi Olivier, Not sure what you mean by "interrupt the process". The new rte_malloc will _mostly_ work just like the old one. There are now two levels of locks: the heap lock, and the system allocation lock. If your rte_malloc call requests amount of memory that can be satisfied by already allocated memory, then only the heap lock is engaged - or, to put it in other words, things work as before. When you *don't* have enough memory allocated, previously rte_malloc would just fail. Now, it instead will lock the second lock and try to allocate more memory from the system. This requires IPC (to ensure all processes have allocated/freed the same memory), so this will take way longer (timeout is set to wait up to 5 seconds, although under normal circumstances it's taking a lot less - depending on how many processes you have running, but ge
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
Hi Anatoly, On Sat, Mar 03, 2018 at 01:45:48PM +, Anatoly Burakov 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, the following limitations are present: > - FreeBSD does not even compile, let alone run > - No 32-bit support > - There are some minor quality-of-life improvements planned that aren't > ready yet and will be part of v2 > - VFIO support is only smoke-tested (but is expected to work), VFIO support > with secondary processes is not tested; work is ongoing to validate VFIO > for all use cases > - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR > IOMMU mode - help from sPAPR maintainers requested > > Nevertheless, this patchset should be testable under 64-bit Linux, and > should work for all use cases bar those mentioned above. > > [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ > [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ > [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ > [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ > [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ > [6] http://dpdk.org/dev/patchwork/patch/34002/ > [7] http://dpdk.org/dev/patchwork/patch/33853/ > [8] http://dpdk.org/dev/patchwork/patch/24484/ I did a quick pass on your patches (unfortunately, I don't have the time to really dive in it). I have few questions/comments: - This is really a big patchset. Thank you for working on this topic. I'll try to test our application with it as soon as possible. - I see from patch 17 that it is possible that rte_malloc() expands the heap by requesting more memory to the OS? Did I understand well? Today, a good property of rte_malloc() compared to malloc() is that it won't interrupt the process (the worst case is a spinlock). This is appreciable on a dataplane core. Will it change? - It's not a big issue, but I have the feeling that the "const" statement is often forgotten in the patchset. I think it is helpful for both optimization, documentation and to detect bugs that modifies/free something that should not. I'm sending some other dummy comments as replies to patches. Thanks, Olivier
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 03-Mar-18 1:45 PM, Anatoly Burakov 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, the following limitations are present: - FreeBSD does not even compile, let alone run - No 32-bit support - There are some minor quality-of-life improvements planned that aren't ready yet and will be part of v2 - VFIO support is only smoke-tested (but is expected to work), VFIO support with secondary processes is not tested; work is ongoing to validate VFIO for all use cases - Dynamic mapping/unmapping memory with VFIO is not supported in sPAPR IOMMU mode - help from sPAPR maintainers requested Nevertheless, this patchset should be testable under 64-bit Linux, and should work for all use cases bar those mentioned above. [1] http://dpdk.org/dev/patchwork/bundle/aburakov/Memory_RFC/ [2] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Fixes/ [3] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Improvements/ [4] http://dpdk.org/dev/patchwork/bundle/aburakov/IPC_Async_Request/ [5] http://dpdk.org/dev/patchwork/bundle/aburakov/Num_Sockets/ [6] http://dpdk.org/dev/patchwork/patch/34002/ [7] http://dpdk.org/dev/patchwork/patch/33853/ [8] http://dpdk.org/dev/patchwork/patch/24484/ For those wanting to test this patchset, there is now a github tree with all of the dependent patches applied: https://github.com/anatolyburakov/dpdk -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On Thu, Mar 08, 2018 at 12:12:15PM +, Burakov, Anatoly wrote:
> On 08-Mar-18 10:53 AM, Nélio Laranjeiro wrote:
> > On Thu, Mar 08, 2018 at 09:37:27AM +, Burakov, Anatoly wrote:
> > > On 07-Mar-18 4:05 PM, Burakov, Anatoly wrote:
> > > > On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote:
> > > > > Hi Anatoly,
> > > > >
> > > > > I am trying to run some test with this series, but it seems to be
> > > > > based
> > > > > on some other commits of yours. I have already identified the
> > > > > following
> > > > > one [1] it seems I am missing some others.
> > > > >
> > > > > It is possible to have a list of commits to apply on the current
> > > > > master
> > > > > branch [2] before this series?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > [1] https://dpdk.org/patch/35043
> > > > > [2]
> > > > > https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c
> > > > >
> > > > >
> > > >
> > > > Hi Nelio,
> > > >
> > > > Yes, my apologies. I'm aware of the apply issues. The issue is due to me
> > > > missing a rebase on one of the dependent patchsets. I'm preparing a v2
> > > > that will fix the issue (pending some internal processes).
> > > >
> > >
> > > Hi Nelio,
> > >
> > > The v2 is now up, with corrected rebase. You can see the list of dependent
> > > patches in the cover letter [1]. Once again apologies for incorrect rebase
> > > in v1. Looking forward to your feedback!
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2018-March/092070.html
> > Hi Anatoly,
> >
> > First feedbacks, I have some issue when compiling it on desktop/server
> > machine with clang and GCC, maybe due some different configuration items
> > depending on the machine compile it.
> >
> > Clang error
> > ---
> >
> >dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:6: error:
> > variable 'have_numa' is used uninitialized whenever 'if' condition is true
> > [-Werror,-Wsometimes-uninitialized]
> > if (!hi) {
> > ^~~
> > CC eal_lcore.o
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note:
> > uninitialized use occurs here
> > if (have_numa)
> > ^
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:2: note: remove
> > the 'if' if its condition is always false
> > if (!hi) {
> > ^~
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:6: error:
> > variable 'have_numa' is used uninitialized whenever 'if' condition is true
> > [-Werror,-Wsometimes-uninitialized]
> > if (internal_config.legacy_mem)
> > ^~
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note:
> > uninitialized use occurs here
> > if (have_numa)
> > ^
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:2: note: remove
> > the 'if' if its condition is always false
> > if (internal_config.legacy_mem)
> > ^~~
> > dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:573:16: note:
> > initialize the variable 'have_numa' to silence this warning
> > bool have_numa;
> > ^
> > = false
> >
> > GCC errors
> > --
> >
> > /root/dpdk/lib/librte_eal/common/eal_common_memzone.c: In function
> > ‘rte_memzone_free’:
> > /root/dpdk/lib/librte_eal/common/eal_common_memzone.c:355:2: error:
> > ‘addr’ may be used uninitialized in this function
> > [-Werror=maybe-uninitialized]
> > rte_free(addr);
> > ^~
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c: In function
> > ‘eal_memalloc_alloc_page_bulk’:
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:5: error:
> > ‘have_numa’ may be used uninitialized in this function
> > [-Werror=maybe-uninitialized]
> > if (have_numa)
> >^
> > cc1: all warnings being treated as errors
> > /root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
> > 'eal_common_memzone.o' failed
> > make[5]: *** [eal_common_memzone.o] Error 1
> > make[5]: *** Waiting for unfinished jobs
> > cc1: all warnings being treated as errors
> > /root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
> > 'eal_memalloc.o' failed
> > make[5]: *** [eal_memalloc.o] Error 1
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c: In function
> > ‘rte_eal_hugepage_attach’:
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1556:7: error:
> > ‘max_seg’ may be used uninitialized in this function
> > [-Werror=maybe-uninitialized]
> > if (cur_seg >= max_seg)
> > ^
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1391:24: note:
> > ‘max_seg’ was declared here
> > unsigned int cur_seg, max_seg;
> > ^~~
> > /root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1389:15: error: ‘i’
> > may be used uninitialized in this function [-W
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 08-Mar-18 10:53 AM, Nélio Laranjeiro wrote:
On Thu, Mar 08, 2018 at 09:37:27AM +, Burakov, Anatoly wrote:
On 07-Mar-18 4:05 PM, Burakov, Anatoly wrote:
On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote:
Hi Anatoly,
I am trying to run some test with this series, but it seems to be based
on some other commits of yours. I have already identified the following
one [1] it seems I am missing some others.
It is possible to have a list of commits to apply on the current master
branch [2] before this series?
Thanks,
[1] https://dpdk.org/patch/35043
[2]
https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c
Hi Nelio,
Yes, my apologies. I'm aware of the apply issues. The issue is due to me
missing a rebase on one of the dependent patchsets. I'm preparing a v2
that will fix the issue (pending some internal processes).
Hi Nelio,
The v2 is now up, with corrected rebase. You can see the list of dependent
patches in the cover letter [1]. Once again apologies for incorrect rebase
in v1. Looking forward to your feedback!
[1] http://dpdk.org/ml/archives/dev/2018-March/092070.html
Hi Anatoly,
First feedbacks, I have some issue when compiling it on desktop/server
machine with clang and GCC, maybe due some different configuration items
depending on the machine compile it.
Clang error
---
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:6: error: variable
'have_numa' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (!hi) {
^~~
CC eal_lcore.o
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note:
uninitialized use occurs here
if (have_numa)
^
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:2: note: remove the
'if' if its condition is always false
if (!hi) {
^~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:6: error: variable
'have_numa' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (internal_config.legacy_mem)
^~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note:
uninitialized use occurs here
if (have_numa)
^
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:2: note: remove the
'if' if its condition is always false
if (internal_config.legacy_mem)
^~~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:573:16: note: initialize
the variable 'have_numa' to silence this warning
bool have_numa;
^
= false
GCC errors
--
/root/dpdk/lib/librte_eal/common/eal_common_memzone.c: In function
‘rte_memzone_free’:
/root/dpdk/lib/librte_eal/common/eal_common_memzone.c:355:2: error: ‘addr’
may be used uninitialized in this function [-Werror=maybe-uninitialized]
rte_free(addr);
^~
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c: In function
‘eal_memalloc_alloc_page_bulk’:
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:5: error:
‘have_numa’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
if (have_numa)
^
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'eal_common_memzone.o' failed
make[5]: *** [eal_common_memzone.o] Error 1
make[5]: *** Waiting for unfinished jobs
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'eal_memalloc.o' failed
make[5]: *** [eal_memalloc.o] Error 1
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c: In function
‘rte_eal_hugepage_attach’:
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1556:7: error: ‘max_seg’
may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (cur_seg >= max_seg)
^
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1391:24: note: ‘max_seg’
was declared here
unsigned int cur_seg, max_seg;
^~~
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1389:15: error: ‘i’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
unsigned int i;
^
It worse to ask Thomas to have a dedicated repository/branch on DPDK,
otherwise it will be a nightmare for anyone who want to test if we need
each time to apply 54 patches.
Can you see it with him?
Thanks,
Hi Nelio,
Thanks for your feedback.
We're working on merging dependencies into the main tree. I've spoken
with Thomas about this, and he suggested to create a GitHub repo for
this patchset, so i'll be looking into this as well.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On Thu, Mar 08, 2018 at 09:37:27AM +, Burakov, Anatoly wrote:
> On 07-Mar-18 4:05 PM, Burakov, Anatoly wrote:
> > On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote:
> > > Hi Anatoly,
> > >
> > > I am trying to run some test with this series, but it seems to be based
> > > on some other commits of yours. I have already identified the following
> > > one [1] it seems I am missing some others.
> > >
> > > It is possible to have a list of commits to apply on the current master
> > > branch [2] before this series?
> > >
> > > Thanks,
> > >
> > > [1] https://dpdk.org/patch/35043
> > > [2]
> > > https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c
> > >
> > >
> >
> > Hi Nelio,
> >
> > Yes, my apologies. I'm aware of the apply issues. The issue is due to me
> > missing a rebase on one of the dependent patchsets. I'm preparing a v2
> > that will fix the issue (pending some internal processes).
> >
>
> Hi Nelio,
>
> The v2 is now up, with corrected rebase. You can see the list of dependent
> patches in the cover letter [1]. Once again apologies for incorrect rebase
> in v1. Looking forward to your feedback!
>
> [1] http://dpdk.org/ml/archives/dev/2018-March/092070.html
Hi Anatoly,
First feedbacks, I have some issue when compiling it on desktop/server
machine with clang and GCC, maybe due some different configuration items
depending on the machine compile it.
Clang error
---
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:6: error: variable
'have_numa' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (!hi) {
^~~
CC eal_lcore.o
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note: uninitialized
use occurs here
if (have_numa)
^
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:590:2: note: remove the
'if' if its condition is always false
if (!hi) {
^~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:6: error: variable
'have_numa' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (internal_config.legacy_mem)
^~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:6: note: uninitialized
use occurs here
if (have_numa)
^
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:580:2: note: remove the
'if' if its condition is always false
if (internal_config.legacy_mem)
^~~
dpdk.org/lib/librte_eal/linuxapp/eal/eal_memalloc.c:573:16: note: initialize
the variable 'have_numa' to silence this warning
bool have_numa;
^
= false
GCC errors
--
/root/dpdk/lib/librte_eal/common/eal_common_memzone.c: In function
‘rte_memzone_free’:
/root/dpdk/lib/librte_eal/common/eal_common_memzone.c:355:2: error: ‘addr’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
rte_free(addr);
^~
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c: In function
‘eal_memalloc_alloc_page_bulk’:
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memalloc.c:693:5: error:
‘have_numa’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
if (have_numa)
^
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'eal_common_memzone.o' failed
make[5]: *** [eal_common_memzone.o] Error 1
make[5]: *** Waiting for unfinished jobs
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'eal_memalloc.o' failed
make[5]: *** [eal_memalloc.o] Error 1
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c: In function
‘rte_eal_hugepage_attach’:
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1556:7: error: ‘max_seg’
may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (cur_seg >= max_seg)
^
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1391:24: note: ‘max_seg’
was declared here
unsigned int cur_seg, max_seg;
^~~
/root/dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c:1389:15: error: ‘i’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
unsigned int i;
^
It worse to ask Thomas to have a dedicated repository/branch on DPDK,
otherwise it will be a nightmare for anyone who want to test if we need
each time to apply 54 patches.
Can you see it with him?
Thanks,
--
Nélio Laranjeiro
6WIND
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 07-Mar-18 4:05 PM, Burakov, Anatoly wrote: On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote: Hi Anatoly, I am trying to run some test with this series, but it seems to be based on some other commits of yours. I have already identified the following one [1] it seems I am missing some others. It is possible to have a list of commits to apply on the current master branch [2] before this series? Thanks, [1] https://dpdk.org/patch/35043 [2] https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c Hi Nelio, Yes, my apologies. I'm aware of the apply issues. The issue is due to me missing a rebase on one of the dependent patchsets. I'm preparing a v2 that will fix the issue (pending some internal processes). Hi Nelio, The v2 is now up, with corrected rebase. You can see the list of dependent patches in the cover letter [1]. Once again apologies for incorrect rebase in v1. Looking forward to your feedback! [1] http://dpdk.org/ml/archives/dev/2018-March/092070.html -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote: Hi Anatoly, I am trying to run some test with this series, but it seems to be based on some other commits of yours. I have already identified the following one [1] it seems I am missing some others. It is possible to have a list of commits to apply on the current master branch [2] before this series? Thanks, [1] https://dpdk.org/patch/35043 [2] https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c Also, the cover letter you're responding to, lists dependent patches as well :) it's just that current patchset does not apply cleanly atop of them due to rebase errors from my side. -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 07-Mar-18 3:27 PM, Nélio Laranjeiro wrote: Hi Anatoly, I am trying to run some test with this series, but it seems to be based on some other commits of yours. I have already identified the following one [1] it seems I am missing some others. It is possible to have a list of commits to apply on the current master branch [2] before this series? Thanks, [1] https://dpdk.org/patch/35043 [2] https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c Hi Nelio, Yes, my apologies. I'm aware of the apply issues. The issue is due to me missing a rebase on one of the dependent patchsets. I'm preparing a v2 that will fix the issue (pending some internal processes). -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
Hi Anatoly, I am trying to run some test with this series, but it seems to be based on some other commits of yours. I have already identified the following one [1] it seems I am missing some others. It is possible to have a list of commits to apply on the current master branch [2] before this series? Thanks, [1] https://dpdk.org/patch/35043 [2] https://dpdk.org/browse/dpdk/commit/?id=c06ddf9698e0c2a9653cfa971f9ddc205065662c -- Nélio Laranjeiro 6WIND
Re: [dpdk-dev] [PATCH 00/41] Memory Hotplug for DPDK
On 03-Mar-18 1:45 PM, Anatoly Burakov wrote: This patchset introduces dynamic memory allocation for DPDK (aka memory hotplug). Based upon RFC submitted in December [1]. For those testing this patch, there's a deadlock-at-startup issue when DPDK is started with no memory. This will be fixed in v2 (as well as dependent IPC patches), but for now the workaround is to start DPDK with -m/--socket-mem switches. -- Thanks, Anatoly
