Hi Anatoly, We'd appreciate your input so we can come to a solution of supporting the necessary memory allocations?
On 23 April 2018 at 02:23, Srinath Mannam <srinath.man...@broadcom.com> wrote: > Hi Anatoly, > > Our requirement is, that separate memory segment (speed memory window) > need to be allocated outside huge pages segment. > your thoughts discussed in the link (dynamic memory allocations in > DPDK) are exactly matches with our requirement. > We tried to fit our requirement in the existing memory model with > minimum changes, So we followed this approach. > Memory model in DPDK managed using socket ids. So I also attached new > memory segment to un-used socket which allows to allocate memory using > rte_malloc. > > Please add me in your discussions. I am very much interested to join > in your discussions and contribute in development. > > Please point me the sources in DPDK related to this part of implementation. > > > Thank you. > > > Regards, > > Srinath. > > > On Thu, Apr 12, 2018 at 8:05 PM, Burakov, Anatoly > <anatoly.bura...@intel.com> wrote: > > On 28-Mar-18 5:51 AM, Ajit Khaparde wrote: > >> > >> From: Srinath Mannam <srinath.man...@broadcom.com> > >> > >> Reserved physical memory is requested from kernel > >> and it will be mapped to user space. > >> This memory will be mapped to IOVA using VFIO. > >> And this memory will be provided to SPDK to allocate > >> NVMe CQs. > >> > >> Signed-off-by: Srinath Mannam <srinath.man...@broadcom.com> > >> Signed-off-by: Scott Branden <scott.bran...@broadcom.com> > >> Signed-off-by: Ajit Khaparde <ajit.khapa...@broadcom.com> > >> --- > > > > > > Hi Srinath, > > > > I've seen this kind of approach implemented before to add additional > memory > > types to DPDK (redefining "unused" socket id's to mean something else), > and > > i don't like it. > > > > What would be better is to design a new API to support different memory > > types. Some groundwork for this was already laid for this release > (switching > > to memseg lists), but more changes will be needed down the line. My ideal > > approach would be to have pluggable memory allocators. I've outlined > some of > > my thoughts on this before [1], you're welcome to join/continue that > > discussion, and make sure whatever comes out of it is going to be useful > for > > all of us :) I was planning to (attempt to) restart that discussion, and > > this seems like as good an opportunity to do that as any other. > > > > Now that the memory hotplug stuff is merged, i'll hopefully get more time > > prototyping. > > > > So, as it is, it's a NACK from me, but let's work together on something > > better :) > > > > [1] http://dpdk.org/ml/archives/dev/2018-February/090937.html > > > > -- > > Thanks, > > Anatoly >
