[dpdk-dev] [PATCH] eal: add request to map reserved physical memory

[Scott Branden]

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.mannam at 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.burakov at intel.com> wrote:
> > On 28-Mar-18 5:51 AM, Ajit Khaparde wrote:
> >>
> >> From: Srinath Mannam <srinath.mannam at 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.mannam at broadcom.com>
> >> Signed-off-by: Scott Branden <scott.branden at broadcom.com>
> >> Signed-off-by: Ajit Khaparde <ajit.khaparde at 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
>