[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250721062600.GA28867@lst.de>
Date: Mon, 21 Jul 2025 08:26:00 +0200
From: Christoph Hellwig <hch@....de>
To: Joel Granados <joel.granados@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
Jens Axboe <axboe@...nel.dk>, 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 Fri, Jul 18, 2025 at 01:33:34PM +0200, Joel Granados wrote:
> > 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
> Do you mean in the specification body or patch series in the mailing
> lists?
Actual code. As I said I very much expect CDQ creation and usage
to be kernel driven for live migration.
> > very much expect the kernel to manage the CDQs just like any other
> > queue, and not a random user ioctl.
> This is a great segue to a question: If CDQ is like any other queue,
> what is the best way of handling the lack of CDQ submission queues?
> Something like snooping all submissions for these CDQs and triggering a
> CDQ consume on every submission?
I don't understand this question and proposed answer at all all.
> I went with the ioctl as the faster way to get it to work;
Get _what_ to work?
> I might
> explore what having it as just another queue would look like.
>
> > So what would be the use case for a user controlled CDQ?
> Do you mean a hypothetical list besides LM in NVME 2.2?
As out line in the last two mails I don't see how live migration would
work with user controlled CDQs. Maybe I'm wrong, but nothing in this
thread seems to even try to explain how that would work.
Powered by blists - more mailing lists