public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Niklas Cassel <cassel@kernel.org>
Cc: Wilfred Mallawa <wilfred.opensource@gmail.com>,
	linux-nvme@lists.infradead.org, Keith Busch <kbusch@kernel.org>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	dlemoal@kernel.org, alistair.francis@wdc.com,
	Wilfred Mallawa <wilfred.mallawa@wdc.com>
Subject: Re: [PATCH 0/5] pci: nvmet: support completion queue sharing by multiple submission queues
Date: Tue, 29 Apr 2025 14:56:48 +0200	[thread overview]
Message-ID: <20250429125648.GB13574@lst.de> (raw)
In-Reply-To: <aAo5xgVOgf0HeFl6@x1-carbon>

On Thu, Apr 24, 2025 at 03:16:54PM +0200, Niklas Cassel wrote:
> Perhaps it is a bit too harsh to say that we are non-spec compliant.

It is not too harsh but simply a true statement.  If the spec
compliance matters or not might be a different question.

> We don't implement every feature in the NVMe spec in the Linux drivers
> on purpose, because there is a lot of feature creep in NVMe.

That is a valid point for optional features.  Sharing a CQ for multiple
SQs is a mandatory feature in PCIe.

This should also get us to the point of running verification test
suite on the PCIe nvmet code, which I'm really looking forward to.


  parent reply	other threads:[~2025-04-29 14:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24  5:13 [PATCH 0/5] pci: nvmet: support completion queue sharing by multiple submission queues Wilfred Mallawa
2025-04-24  5:13 ` [PATCH 1/5] nvmet: add a helper function for cqid checking Wilfred Mallawa
2025-05-07  7:20   ` Damien Le Moal
2025-04-24  5:13 ` [PATCH 2/5] nvmet: cq: prepare for completion queue sharing Wilfred Mallawa
2025-05-07  7:25   ` Damien Le Moal
2025-05-07  7:34     ` Wilfred Mallawa
2025-05-07  7:38       ` Damien Le Moal
2025-05-07  7:47         ` Wilfred Mallawa
2025-04-24  5:13 ` [PATCH 3/5] nvmet: fabrics: add CQ init and destroy Wilfred Mallawa
2025-05-07  7:27   ` Damien Le Moal
2025-04-24  5:13 ` [PATCH 4/5] nvmet: support completion queue sharing Wilfred Mallawa
2025-05-07  7:29   ` Damien Le Moal
2025-04-24  5:13 ` [PATCH 5/5] nvmet: Simplify nvmet_req_init() interface Wilfred Mallawa
2025-05-07  7:29   ` Damien Le Moal
2025-04-24 13:16 ` [PATCH 0/5] pci: nvmet: support completion queue sharing by multiple submission queues Niklas Cassel
2025-04-25  1:22   ` Damien Le Moal
2025-04-29 12:56   ` Christoph Hellwig [this message]
2025-05-07  7:32 ` Damien Le Moal
2025-05-09  5:05 ` Christoph Hellwig
2025-05-11 23:05 ` Chaitanya Kulkarni

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=20250429125648.GB13574@lst.de \
    --to=hch@lst.de \
    --cc=alistair.francis@wdc.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=wilfred.mallawa@wdc.com \
    --cc=wilfred.opensource@gmail.com \
    /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