All of lore.kernel.org
 help / color / mirror / Atom feed
From: sagi@grimberg.me (Sagi Grimberg)
Subject: [RFC PATCH 0/8] nvmet: implement target passthru commands support
Date: Wed, 4 Apr 2018 14:44:11 +0300	[thread overview]
Message-ID: <e089febc-577f-354d-dceb-0410d9115e1f@grimberg.me> (raw)
In-Reply-To: <20180330065747.20962-1-chaitanya.kulkarni@wdc.com>


> Hi,

Hi Chaitanya,

> This patchset implements NVMeOF target passthrough commands support.
> 
> In current implementation on the target side, NVMe command is mapped on the
> block layer request which allows the target to use generic block device.

So for normal IO commands, I would simply move the bio construction loop
to shared code and call it from either the normal nvmet_execute_* or
nvmet_execute_passthru_io_cmd. I still don't understand what that buys
us... I guess one benefit would be to utilize ranged (merged) discards
instead of executing them range by range...

For admin commands I would do something different though, why not simply
exporting __nvme_passthru_cmd (portion of nvme_user_cmd) and simply call
that with a bit of tweaks to the host memory layout. That would
eliminate the re-code in nvmet_execute_admin_cmd() Thoughts?

> With the help of passthrough interface, it can now identify the NVMe controller
> and allow the host to issue NVMe commands along with the VUCs on the
> target side.

We need code to exclude more than a single access to the same passthru
controller (or subsystem in fact). Otherwise we might be exposing the
user to lots of troubles...

Its also odd that a namespace is given a passthru access to a
controller. Maybe we need to add a configfs interface for passthru
subsystems? (under subsystems/ we have passthru file that takes the
controller name or subsystem id or something)

Then automatically all the namespaces of that controller will be exposed
via the subsystem (or fail if namespaces are already attached to
other subsystems).

> For example with this feature, depending on the target controller
> support host can issue namespace management commands,
> Vendor unique commands etc.

So namespace management needs a mechanism to add the new namespace via
the fabrics target. This would require adding an event client mechanism
to nvme that will create that namespace in nvmet before issuing the
AEN.

  parent reply	other threads:[~2018-04-04 11:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30  6:57 [RFC PATCH 0/8] nvmet: implement target passthru commands support Chaitanya Kulkarni
2018-03-30  6:57 ` [RFC PATCH 1/8] nvme-core: add new interfaces Chaitanya Kulkarni
2018-03-30 17:48   ` Logan Gunthorpe
2018-04-02 23:25     ` Chaitanya Kulkarni
2018-04-04 11:52   ` Sagi Grimberg
2018-04-13 17:27     ` Christoph Hellwig
2018-03-30  6:57 ` [RFC PATCH 2/8] nvme-core: export existing ctrl and ns interfaces Chaitanya Kulkarni
2018-04-04 11:59   ` Sagi Grimberg
2018-03-30  6:57 ` [RFC PATCH 3/8] nvmet: add passthru members in target subsys Chaitanya Kulkarni
2018-03-30  6:57 ` [RFC PATCH 4/8] nvmet: use const values for id-ctrl Chaitanya Kulkarni
2018-03-30 18:50   ` Logan Gunthorpe
2018-04-02 23:27     ` Chaitanya Kulkarni
2018-04-13 17:28     ` Christoph Hellwig
2018-03-30  6:57 ` [RFC PATCH 5/8] nvmet: export nvmet_add_async_event api Chaitanya Kulkarni
2018-03-30  6:57 ` [RFC PATCH 6/8] nvmet: add target passthru command support Chaitanya Kulkarni
2018-03-30  6:57 ` [RFC PATCH 7/8] nvmet: integrate passthru code with target core Chaitanya Kulkarni
2018-03-30  6:57 ` [RFC PATCH 8/8] nvmet: add configfs interface for target passthru Chaitanya Kulkarni
2018-03-30 18:13   ` Logan Gunthorpe
2018-04-03  0:13     ` Chaitanya Kulkarni
2018-04-03  3:21       ` Logan Gunthorpe
2018-04-13 17:30     ` Christoph Hellwig
2018-04-13 17:37       ` Logan Gunthorpe
2018-04-13 21:50         ` Stephen  Bates
2018-03-30 17:46 ` [RFC PATCH 0/8] nvmet: implement target passthru commands support Logan Gunthorpe
2018-04-02 23:23   ` Chaitanya Kulkarni
2018-04-04 11:44 ` Sagi Grimberg [this message]
2018-04-13 17:35   ` Christoph Hellwig

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=e089febc-577f-354d-dceb-0410d9115e1f@grimberg.me \
    --to=sagi@grimberg.me \
    /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.