Re: [PATCH RFC] nvme-ioctl: propagate PRP1 from ioctl to admin cmd

[Christoph Hellwig <hch@lst.de>]

On Tue, Jun 23, 2026 at 06:19:08AM -0600, Keith Busch wrote:
> On Tue, Jun 23, 2026 at 12:34:29PM +0200, David Epping wrote:
> > My question is, and maybe I should have put this in my initial email
> > explicitely, is there interest in having such functionality in the upstream
> > Linux in-Kernel NVMe driver? An interface and mechanism to request and
> > manage IO queues that are not used by the Linux NVMe driver to perform IO,
> > but handed to a separate entity for this purpose.
> 
> Partitioning device resources to assign to special purposes should be
> under a well defined framework. Unfortunately the only thing I know of
> approaching this is SIOV. :) Not sure how other maintainers and
> developers feel about it, but that's the route I would go for this. It
> at least provides memory access on a queue granularity and neatly
> separates the control plane.

Yeah, we can't just hand out queues.  I/O to all namespaces can be done
on queue, and any queue can address any IOVA, so this is fundamentally
unsafe.  Add to that fun like abort handling and it's just not going
to work at all.  We had at least to previous public attempts at such
schemes (Damiens' libvnme back in the day, and the Mellanox nvmet
offloading) that were rejected for the same reason.