Hi James,

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?

Sincerely,

E.

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@lists.01.org> on behalf of Ernest Zaslavsky <kreuzerkrieg@gmail.com>
Reply-To: Storage Performance Development Kit <spdk@lists.01.org>
Date: Tuesday, February 6, 2018 at 6:32 AM
To: "spdk@lists.01.org" <spdk@lists.01.org>
Subject: [SPDK] Memory buffer allocation in SPDK

Hi,

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 questions:

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?

Hi Ernest,

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.

Regards,

-Jim