All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>, keith.busch@intel.com
Cc: linux-block@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-nvme@lists.infradead.org
Subject: Re: NVMe over Fabrics target implementation V2
Date: Tue, 5 Jul 2016 11:31:10 -0600	[thread overview]
Message-ID: <577BEEDE.8060607@kernel.dk> (raw)
In-Reply-To: <1466525061-3686-1-git-send-email-hch@lst.de>

On 06/21/2016 10:04 AM, Christoph Hellwig wrote:
> This patch set adds a generic NVMe over Fabrics target. The
> implementation conforms to the NVMe 1.2b specification (which
> includes Fabrics) and provides the NVMe over Fabrics access
> to Linux block devices.
>
> The target implementation consists of several elements:
>
> - NVMe target core: defines and manages the NVMe entities (subsystems,
>    controllers, namespaces, ...) and their allocation, responsible
>    for initial commands processing and correct orchestration of
>    the stack setup and tear down.
>
> - NVMe admin command implementation: responsible for parsing and
>    servicing admin commands such as controller identify, set features,
>    keep-alive, log page, ...).
>
> - NVMe I/O command implementation: responsible for performing the actual
>    I/O (Read, Write, Flush, Deallocate (aka Discard).  It is a very thin
>    layer on top of the block layer and implements no logic of it's own.
>    To support exporting file systems please use the loopback block driver
>    in direct I/O mode, which gives very good performance.
>
> - NVMe over Fabrics support: responsible for servicing Fabrics commands
>    (connect, property get/set).
>
> - NVMe over Fabrics discovery service: responsible to serve the Discovery
>    log page through a special cut down Discovery controller.
>
> The target is configured using configfs, and configurable entities are:
>
>   - NVMe subsystems and namespaces
>   - NVMe over Fabrics ports and referrals
>   - Host ACLs for primitive access control - NVMe over Fabrics access
>     control is still work in progress at the specification level and
>     will be implemented once that work has finished.
>
> To configure the target use the nvmetcli tool from
> http://git.infradead.org/users/hch/nvmetcli.git, which includes detailed
> setup documentation.
>
> In addition to the Fabrics target implementation we provide a loopback
> driver which also conforms the NVMe over Fabrics specification and allows
> evaluation of the target stack with local access without requiring a real
> fabric.
>
> Various test cases are provided for this implementation: nvmetcli
> contains a python testsuite that mostly stresses the configfs interface
> of the target, and we have various integration tests prepared for the
> kernel host and target which are available at:
>
> 	git://git.infradead.org/nvme-fabrics.git nvmf-submit.2
>
> Gitweb:
>
> 	http://git.infradead.org/nvme-fabrics.git/shortlog/refs/heads/nvmf-submit.2
>
> This series depends on the "generic NVMe over Fabrics library support V2"
> series submitted last week.
>
> Changes since V1:
>   - rebased to the req_op changes in the block tree (me)
>   - fix a 64-bit division (me)
>   - properly set the SGL flag for AER requests in nvme-loop (me)
>   - fix use of ERR_PTR (buildbot)

Applied for 4.8, thanks.

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: axboe@kernel.dk (Jens Axboe)
Subject: NVMe over Fabrics target implementation V2
Date: Tue, 5 Jul 2016 11:31:10 -0600	[thread overview]
Message-ID: <577BEEDE.8060607@kernel.dk> (raw)
In-Reply-To: <1466525061-3686-1-git-send-email-hch@lst.de>

On 06/21/2016 10:04 AM, Christoph Hellwig wrote:
> This patch set adds a generic NVMe over Fabrics target. The
> implementation conforms to the NVMe 1.2b specification (which
> includes Fabrics) and provides the NVMe over Fabrics access
> to Linux block devices.
>
> The target implementation consists of several elements:
>
> - NVMe target core: defines and manages the NVMe entities (subsystems,
>    controllers, namespaces, ...) and their allocation, responsible
>    for initial commands processing and correct orchestration of
>    the stack setup and tear down.
>
> - NVMe admin command implementation: responsible for parsing and
>    servicing admin commands such as controller identify, set features,
>    keep-alive, log page, ...).
>
> - NVMe I/O command implementation: responsible for performing the actual
>    I/O (Read, Write, Flush, Deallocate (aka Discard).  It is a very thin
>    layer on top of the block layer and implements no logic of it's own.
>    To support exporting file systems please use the loopback block driver
>    in direct I/O mode, which gives very good performance.
>
> - NVMe over Fabrics support: responsible for servicing Fabrics commands
>    (connect, property get/set).
>
> - NVMe over Fabrics discovery service: responsible to serve the Discovery
>    log page through a special cut down Discovery controller.
>
> The target is configured using configfs, and configurable entities are:
>
>   - NVMe subsystems and namespaces
>   - NVMe over Fabrics ports and referrals
>   - Host ACLs for primitive access control - NVMe over Fabrics access
>     control is still work in progress at the specification level and
>     will be implemented once that work has finished.
>
> To configure the target use the nvmetcli tool from
> http://git.infradead.org/users/hch/nvmetcli.git, which includes detailed
> setup documentation.
>
> In addition to the Fabrics target implementation we provide a loopback
> driver which also conforms the NVMe over Fabrics specification and allows
> evaluation of the target stack with local access without requiring a real
> fabric.
>
> Various test cases are provided for this implementation: nvmetcli
> contains a python testsuite that mostly stresses the configfs interface
> of the target, and we have various integration tests prepared for the
> kernel host and target which are available at:
>
> 	git://git.infradead.org/nvme-fabrics.git nvmf-submit.2
>
> Gitweb:
>
> 	http://git.infradead.org/nvme-fabrics.git/shortlog/refs/heads/nvmf-submit.2
>
> This series depends on the "generic NVMe over Fabrics library support V2"
> series submitted last week.
>
> Changes since V1:
>   - rebased to the req_op changes in the block tree (me)
>   - fix a 64-bit division (me)
>   - properly set the SGL flag for AER requests in nvme-loop (me)
>   - fix use of ERR_PTR (buildbot)

Applied for 4.8, thanks.

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
To: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Cc: linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: NVMe over Fabrics target implementation V2
Date: Tue, 5 Jul 2016 11:31:10 -0600	[thread overview]
Message-ID: <577BEEDE.8060607@kernel.dk> (raw)
In-Reply-To: <1466525061-3686-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>

On 06/21/2016 10:04 AM, Christoph Hellwig wrote:
> This patch set adds a generic NVMe over Fabrics target. The
> implementation conforms to the NVMe 1.2b specification (which
> includes Fabrics) and provides the NVMe over Fabrics access
> to Linux block devices.
>
> The target implementation consists of several elements:
>
> - NVMe target core: defines and manages the NVMe entities (subsystems,
>    controllers, namespaces, ...) and their allocation, responsible
>    for initial commands processing and correct orchestration of
>    the stack setup and tear down.
>
> - NVMe admin command implementation: responsible for parsing and
>    servicing admin commands such as controller identify, set features,
>    keep-alive, log page, ...).
>
> - NVMe I/O command implementation: responsible for performing the actual
>    I/O (Read, Write, Flush, Deallocate (aka Discard).  It is a very thin
>    layer on top of the block layer and implements no logic of it's own.
>    To support exporting file systems please use the loopback block driver
>    in direct I/O mode, which gives very good performance.
>
> - NVMe over Fabrics support: responsible for servicing Fabrics commands
>    (connect, property get/set).
>
> - NVMe over Fabrics discovery service: responsible to serve the Discovery
>    log page through a special cut down Discovery controller.
>
> The target is configured using configfs, and configurable entities are:
>
>   - NVMe subsystems and namespaces
>   - NVMe over Fabrics ports and referrals
>   - Host ACLs for primitive access control - NVMe over Fabrics access
>     control is still work in progress at the specification level and
>     will be implemented once that work has finished.
>
> To configure the target use the nvmetcli tool from
> http://git.infradead.org/users/hch/nvmetcli.git, which includes detailed
> setup documentation.
>
> In addition to the Fabrics target implementation we provide a loopback
> driver which also conforms the NVMe over Fabrics specification and allows
> evaluation of the target stack with local access without requiring a real
> fabric.
>
> Various test cases are provided for this implementation: nvmetcli
> contains a python testsuite that mostly stresses the configfs interface
> of the target, and we have various integration tests prepared for the
> kernel host and target which are available at:
>
> 	git://git.infradead.org/nvme-fabrics.git nvmf-submit.2
>
> Gitweb:
>
> 	http://git.infradead.org/nvme-fabrics.git/shortlog/refs/heads/nvmf-submit.2
>
> This series depends on the "generic NVMe over Fabrics library support V2"
> series submitted last week.
>
> Changes since V1:
>   - rebased to the req_op changes in the block tree (me)
>   - fix a 64-bit division (me)
>   - properly set the SGL flag for AER requests in nvme-loop (me)
>   - fix use of ERR_PTR (buildbot)

Applied for 4.8, thanks.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-07-05 17:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 16:04 NVMe over Fabrics target implementation V2 Christoph Hellwig
2016-06-21 16:04 ` Christoph Hellwig
2016-06-21 16:04 ` Christoph Hellwig
2016-06-21 16:04 ` [PATCH 1/3] block: Export blk_poll Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-21 16:04 ` [PATCH 2/3] nvmet: add a generic NVMe target Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-21 16:04 ` [PATCH 3/3] nvme-loop: add a NVMe loopback host driver Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-21 16:04   ` Christoph Hellwig
2016-06-28 19:02 ` NVMe over Fabrics target implementation V2 Steve Wise
2016-06-28 19:02   ` Steve Wise
2016-06-28 19:02   ` Steve Wise
2016-07-05 17:31 ` Jens Axboe [this message]
2016-07-05 17:31   ` Jens Axboe
2016-07-05 17:31   ` Jens Axboe
2016-07-13  9:38   ` Sagi Grimberg
2016-07-13  9:38     ` Sagi Grimberg
2016-07-13  9:38     ` Sagi Grimberg

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=577BEEDE.8060607@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-rdma@vger.kernel.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.