Thanks for the info, sounds like we have a way to solve our problem. I have some
additional questions. The spdk_mem_register() function, it just adds the region to the
SPDK allocation map, right? It does not touch or modifies the memory in any way, right? Is
it safe to say that we may register with SPDK all our pre-allocated memory when the
application starts and just keep it that way?
From: Harris, James R
Sent: Wednesday, February 7, 2018 2:11 AM
To: Storage Performance Development Kit
Subject: Re: [SPDK] Memory buffer allocation in SPDK
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of Ernest Zaslavsky
Reply-To: Storage Performance Development Kit <spdk(a)lists.01.org>
Date: Tuesday, February 6, 2018 at 6:32 AM
To: "spdk(a)lists.01.org" <spdk(a)lists.01.org>
Subject: [SPDK] Memory buffer allocation in SPDK
I’ve found this discussion https://lists.01.org/pipermail/spdk/2016-December/000251.html
on memory allocation. I have similar situation – our application uses some allocator to
create IO buffers, but of course, SPDK would not accept such a buffer. So I have two
1) I cant find in code the spdk_vtophys_register() mentioned in the above link, is it
removed? If not, where is it? How to use it?
spdk_mem_register() is the equivalent function now. This will register the specified
buffer not only for virtual-to-physical address translation, but also for RDMA operations
using the SPDK NVMe-oF driver.
2) In case our allocator uses hugepages and it is aligned on 4Kib boundary, is there a way
to make the SPDK believe that this buffer could be used for NVMe IO?
spdk_mem_register() is the function to use. Note that currently for vtophys translation,
the specified buffer must be 2MiB aligned and an even 2MiB multiple.