[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250714130230.GA7752@lst.de>
Date: Mon, 14 Jul 2025 15:02:31 +0200
From: Christoph Hellwig <hch@....de>
To: Joel Granados <joel.granados@...nel.org>
Cc: Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
Klaus Jensen <k.jensen@...sung.com>, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/8] nvme: Add Controller Data Queue to the nvme
driver
On Mon, Jul 14, 2025 at 11:15:31AM +0200, Joel Granados wrote:
> Motivation
> ==========
> The main motivation is to enable Controller Data Queues as described in
> the 2.2 revision of the NVME base specification. This series places the
> kernel as an intermediary between the NVME controller producing CDQ
> entries and the user space process consuming them. It is general enough
> to encompass different use cases that require controller initiated
> communication delivered outside the regular I/O traffic streams (like
> LBA tracking for example).
That's rather blurbish. The only use case for CDQs in NVMe 2.2 is
tracking of dirty LBAs for live migration, and the live migration
feature in 2.2 is completely broken because the hyperscalers wanted
to win a point. So for CDQs to be useful in Linux we'll need the
proper live migration still under heavy development. With that I'd
very much expect the kernel to manage the CDQs just like any other
queue, and not a random user ioctl. So what would be the use case for
a user controlled CDQ?
Powered by blists - more mailing lists