From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============7383953804569074539=="
MIME-Version: 1.0
From: Walker, Benjamin <benjamin.walker at intel.com>
Subject: Re: [SPDK] SPDK + user space appliance
Date: Fri, 02 Feb 2018 21:43:58 +0000
Message-ID: <1517607836.2371.98.camel@intel.com>
In-Reply-To: DB6PR04MB3080A83BB9D38D31EB78944789FA0@DB6PR04MB3080.eurprd04.prod.outlook.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============7383953804569074539==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Thu, 2018-02-01 at 08:29 +0000, Shahar Salzman wrote:
> Hi Ben,
> =

> Would you also like to take a look at the bdev_user module?
> It still needs some patching (as some of the stuff is still hard coded), =
but I
> think we can get most of it cleaned up in a couple of days.
> =

> In any case, is it the intention that the user write his own bdev module,=
 or
> would this user appliance glue be a useful generic module?

For existing storage stacks that serve block I/O, like the internals of a S=
AN,
the idea is that you write your own bdev module to forward I/O coming out o=
f the
SPDK bdev layer. Then you can use the SPDK iSCSI/NVMe-oF/vhost targets most=
ly
as-is.

In some cases, the actual iSCSI/NVMe-oF/vhost target applications won't
integrate nicely directly into an existing storage application because they
spawn their own threads and allocate their own memory. To support that, the
libraries may be consumed directly instead of the applications (lib/iscsi,
lib/scsi, lib/nvmf, etc.). The libraries don't spawn any of their own threa=
ds,
but instead rely on SPDK's abstractions in include/spdk/io_channel.h. See

http://www.spdk.io/doc/concurrency.html

We don't currently have a way to write a custom bdev module that resides ou=
tside
of the SPDK source tree, but it's very possible to add support for that. But
beyond that inconvenience (just drop your module in lib/bdev for now), writ=
ing a
bdev module is the recommended way of interacting with the bottom end of the
SPDK bdev layer. I think that's what you really want to be doing in your co=
de,
from what I can tell.

I hope that helps!
--===============7383953804569074539==--