From: Andrey Nikitin <nikitina@amazon.com>
To: <linux-nvme@lists.infradead.org>
Cc: <benh@kernel.crashing.org>, <davebuch@amazon.com>,
Andrey Nikitin <nikitina@amazon.com>
Subject: [RFC PATCH 0/3] nvme sq associations
Date: Fri, 24 Sep 2021 21:08:06 +0000 [thread overview]
Message-ID: <20210924210809.14536-1-nikitina@amazon.com> (raw)
The NVMe specification allows for namespaces with different performance
characteristics, as well as allowing IOs submissions to any namespace via
any non-empty submission queue. However, sharing queue resources between
namespaces with different performance characteristics can cause undesired
behavior (e.g. head-of-line-blocking for IOs that target a high-performance
namespace behind IOs that target a low performance namespace via the same
queue). In addition, the lack of hardware queue isolation support can cause
“noisy neighbor” type problems for applications issuing IOs to different
namespaces of the same controller. This problem may be especially pronounced
in multi-tenant environments such as the ones provided by cloud services.
The NVMe 1.4 specification has introduced some optional features (NVM sets
and SQ associations) that can be utilized to improve this situation provided
these features are supported by both controllers and host drivers. Namespaces
can be assigned to NVM sets (by performance characteristics, for example)
which each NVM set having its own set of associated queues.
This patch series proposes a simple implementation of NVM sets and
SQ associations for the NVMe host PCI module. A controller that supports
these features, along with a sufficient number of queue pairs (at least
one per NVM set), will have the available queue pairs associated uniformly
across each NVM set. IO requests directed at the controller will honor
the namespace/NVM set/queue association by virtue of each NVM set having
its own blk-mq tagset associated with it.
Andrey Nikitin (3):
nvme: split admin queue in pci
nvme: add NVM set structures
nvme: implement SQ associations
drivers/nvme/host/core.c | 18 +-
drivers/nvme/host/fc.c | 1 +
drivers/nvme/host/nvme.h | 10 +
drivers/nvme/host/pci.c | 363 +++++++++++++++++++++++++------------
drivers/nvme/host/rdma.c | 1 +
drivers/nvme/host/tcp.c | 1 +
drivers/nvme/target/loop.c | 1 +
include/linux/nvme.h | 11 +-
8 files changed, 286 insertions(+), 120 deletions(-)
--
2.32.0
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next reply other threads:[~2021-09-24 21:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 21:08 Andrey Nikitin [this message]
2021-09-24 21:08 ` [RFC PATCH 1/3] nvme: split admin queue in pci Andrey Nikitin
2021-09-24 21:08 ` [RFC PATCH 2/3] nvme: add NVM set structures Andrey Nikitin
2021-09-24 21:08 ` [RFC PATCH 3/3] nvme: implement SQ associations Andrey Nikitin
2021-09-25 3:02 ` [RFC PATCH 0/3] nvme sq associations Keith Busch
2021-09-25 8:31 ` Benjamin Herrenschmidt
2021-09-25 8:36 ` Christoph Hellwig
2021-09-29 6:07 ` Chaitanya Kulkarni
2021-09-29 13:17 ` Sagi Grimberg
2021-09-29 0:48 Nikitin, Andrey
2021-09-29 1:35 ` Keith Busch
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=20210924210809.14536-1-nikitina@amazon.com \
--to=nikitina@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=davebuch@amazon.com \
--cc=linux-nvme@lists.infradead.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.