From: Scott Branden <scott.branden@broadcom.com>
To: Srinath Mannam <srinath.mannam@broadcom.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] eal: add request to map reserved physical memory
Date: Fri, 27 Apr 2018 09:30:11 -0700 [thread overview]
Message-ID: <CA+JzhdK0tkHu3=ci8CAnfUrF8sCGGVM6chBk+6TYWg2W-gbvOA@mail.gmail.com> (raw)
In-Reply-To: <CABe79T6Obk=+cSLMQmZtDfwt8j7FJVQKGRXE2tK=5pUNabLkJQ@mail.gmail.com>
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@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@intel.com> wrote:
> > On 28-Mar-18 5:51 AM, Ajit Khaparde wrote:
> >>
> >> From: Srinath Mannam <srinath.mannam@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@broadcom.com>
> >> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> >> Signed-off-by: Ajit Khaparde <ajit.khaparde@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
>
next prev parent reply other threads:[~2018-04-27 16:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 4:51 Ajit Khaparde
2018-04-12 14:35 ` Burakov, Anatoly
2018-04-23 9:23 ` Srinath Mannam
2018-04-27 16:30 ` Scott Branden [this message]
2018-04-27 16:49 ` Burakov, Anatoly
2018-04-27 17:09 ` Scott Branden
2018-06-06 0:18 ` Scott Branden
2018-06-07 12:15 ` Burakov, Anatoly
2018-07-09 16:02 ` Burakov, Anatoly
2018-07-09 16:12 ` Srinath Mannam
2018-07-09 20:44 ` Scott Branden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+JzhdK0tkHu3=ci8CAnfUrF8sCGGVM6chBk+6TYWg2W-gbvOA@mail.gmail.com' \
--to=scott.branden@broadcom.com \
--cc=ajit.khaparde@broadcom.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=srinath.mannam@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).