From: hch@lst.de (Christoph Hellwig)
Subject: NVMe over Fabrics target implementation
Date: Tue, 7 Jun 2016 12:55:50 +0200 [thread overview]
Message-ID: <20160607105550.GB17113@lst.de> (raw)
In-Reply-To: <1465280632.5365.58.camel@haakon3.risingtidesystems.com>
There is absolutely no point in dragging in an overcomplicated configfs
structure for a very simple protocol which also is very different from
SCSI in it's nitty gritty details. Keeping the nvme target self contains
allows it to be both much simpler and much easier to understand, as well
as much better testable - see the amount of test coverage we could easily
add for example.
Or to put it the other way around - if there was any major synergy in
reusing the SCSI target code that just shows we're missing functionality
in the block layer or configfs.
The only thing where this is the case mid-term is persistent reservations,
but Mike Christie already has a plan for a pluggable PR API, which I'm
very interested in.
next prev parent reply other threads:[~2016-06-07 10:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 21:22 NVMe over Fabrics target implementation Christoph Hellwig
2016-06-06 21:22 ` [PATCH 1/3] block: Export blk_poll Christoph Hellwig
2016-06-07 6:49 ` Nicholas A. Bellinger
2016-06-06 21:22 ` [PATCH 2/3] nvmet: add a generic NVMe target Christoph Hellwig
2016-06-06 21:22 ` [PATCH 3/3] nvme-loop: add a NVMe loopback host driver Christoph Hellwig
2016-06-06 22:00 ` kbuild test robot
2016-06-07 6:23 ` NVMe over Fabrics target implementation Nicholas A. Bellinger
2016-06-07 10:55 ` Christoph Hellwig [this message]
2016-06-08 5:21 ` Nicholas A. Bellinger
2016-06-08 12:19 ` Christoph Hellwig
2016-06-08 13:12 ` Sagi Grimberg
2016-06-08 13:46 ` Christoph Hellwig
2016-06-09 4:36 ` Nicholas A. Bellinger
2016-06-09 13:46 ` Christoph Hellwig
2016-06-09 3:32 ` Nicholas A. Bellinger
2016-06-07 21:02 ` Andy Grover
2016-06-07 21:10 ` Ming Lin
2016-06-07 17:01 ` Bart Van Assche
2016-06-07 17:31 ` Christoph Hellwig
2016-06-07 18:11 ` Bart Van Assche
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=20160607105550.GB17113@lst.de \
--to=hch@lst.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).