From: Harris, James R <james.r.harris at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] SPDK NVMe CMB WDS/RDS Support: Thanks and next steps!
Date: Thu, 15 Feb 2018 21:15:17 +0000 [thread overview]
Message-ID: <21421AB2-A85B-4564-AB9D-E9CB0F478DB0@intel.com> (raw)
In-Reply-To: 41EA3D38-F61B-442A-B09F-D8A1DACCEE5E@raithlin.com
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
On 2/15/18, 2:02 PM, "Stephen Bates" <sbates(a)raithlin.com> wrote:
Jim
> We also need a better CMB allocation scheme.
Ha! I knew there was a feature I was forgetting. This is it. Yes for sure, thanks for reminding me. I have added it to my list so I don't forget next time.
Do we have anything like this in SPDK already or does anyone have any pointers to a licence compatible open-source allocator that might suit our needs?
There’s really nothing like this today in SPDK. I believe DPDK provides a way to use their allocators with “user-provided” memory – i.e. not from the hugepages allocated in host memory by DPDK. But I haven’t looked at exactly how that works.
I guess I’m not 100% sold that we need a full-blown allocator. Maybe what we have currently is enough – the user can allocate the memory but it’s up to the user how it is managed. Meaning that the free_cmb_io_buffer routine effectively goes away. And just be explicit in the API – i.e. here’s the call you make to get the CMB buffer and its size – what you choose to do with it is your business. We could always provide some kind of allocator later – but that can be done outside of the SPDK NVMe CMB logic itself.
I’m curious – how much CMB does one of your NoLoad card have?
-Jim
next reply other threads:[~2018-02-15 21:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 21:15 Harris, James R [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-02-26 19:31 [SPDK] SPDK NVMe CMB WDS/RDS Support: Thanks and next steps! Stephen Bates
2018-02-21 20:58 Stephen Bates
2018-02-21 20:43 Harris, James R
2018-02-21 20:39 Stephen Bates
2018-02-15 23:18 Stephen Bates
2018-02-15 22:32 Stephen Bates
2018-02-15 21:02 Stephen Bates
2018-02-15 15:32 Harris, James R
2018-02-15 15:02 Luse, Paul E
2018-02-15 14:32 Stephen Bates
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=21421AB2-A85B-4564-AB9D-E9CB0F478DB0@intel.com \
--to=spdk@lists.01.org \
/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