All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shahar Salzman <shahar.salzman at kaminario.com>
To: spdk@lists.01.org
Subject: [SPDK] SPDK + user space appliance
Date: Sun, 14 Jan 2018 09:09:36 +0000	[thread overview]
Message-ID: <AM5PR04MB307489E0EB9C162E7F761E3D89150@AM5PR04MB3074.eurprd04.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

Hi experts,


We have been integrating spdk into our system using a blockdev module, currently only a POC version.

Our use case is a user space appliance processing IOs, with an SPDK frontend to do the NVMeF.


Currently all of the user bdevs are created via configuration file, but we are working to add functions + rpc's which allow creation/deletion of these namespaces.

IO is sent to user space via callback, implementation is up to user space, but obviously the longer it lingers there the lower the performance, we use a set of rings + threads processing them, so that the time spent in the appliance is minimal.

Going back from user space we use a single ring (multiple producers single consumer) onto which the completions are inserted, and the ring poll function is registered with spdk core (spdk_poller_register).


Does this seem like a sane design? We'd really like your feedback, and if this can be useful to others, push the code into spdk.

Obviously we are willing to go through any review/testing process that is required. And share performance results and issues.


Cheers,

Shahar

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2553 bytes --]

             reply	other threads:[~2018-01-14  9:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-14  9:09 Shahar Salzman [this message]
2018-01-18 23:53 [SPDK] SPDK + user space appliance Chang, Cunyin
2018-01-19 17:28 Walker, Benjamin
2018-01-19 17:38 Aneesh Pachilangottil
2018-01-19 17:48 Walker, Benjamin
2018-01-23  8:20 Ilan Steinberg
2018-01-23  8:21 Ilan Steinberg
2018-01-25 14:19 Shahar Salzman
2018-01-31 16:40 Walker, Benjamin
2018-01-31 16:48 Walker, Benjamin
2018-02-01  8:29 Shahar Salzman
2018-02-02 21:43 Walker, Benjamin
2018-04-23 15:44 Shahar Salzman
2018-04-24 16:19 Walker, Benjamin
2018-04-25  6:02 Shahar Salzman
2018-05-03  8:00 Shahar Salzman
2018-05-03 17:50 Verkamp, Daniel
2018-05-06 10:32 Shahar Salzman
2018-05-07 18:02 Walker, Benjamin
2018-05-07 18:18 Harris, James R
2018-05-08  7:36 Shahar Salzman
2018-05-08 17:30 Walker, Benjamin
2018-05-09  7:48 Shahar Salzman
2018-05-09  8:43 
2018-05-09  9:54 
2018-05-09 11:57 Shahar Salzman
2018-05-09 16:52 Walker, Benjamin
2018-05-09 19:45 Shahar Salzman
2018-05-10  6:34 
2018-05-10  7:36 
2018-05-10 13:33 Shahar Salzman
2018-05-11 13:11 
2018-05-13  8:46 Shahar Salzman
2018-07-12 14:34 Shahar Salzman
2018-07-16 22:58 

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=AM5PR04MB307489E0EB9C162E7F761E3D89150@AM5PR04MB3074.eurprd04.prod.outlook.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.