[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260108101703.GA24709@lst.de>
Date: Thu, 8 Jan 2026 11:17:03 +0100
From: Christoph Hellwig <hch@....de>
To: Ming Lei <ming.lei@...hat.com>
Cc: Christoph Hellwig <hch@....de>,
Christian König <christian.koenig@....com>,
Pavel Begunkov <asml.silence@...il.com>,
linux-block@...r.kernel.org, io-uring@...r.kernel.org,
Vishal Verma <vishal1.verma@...el.com>, tushar.gohad@...el.com,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Sagi Grimberg <sagi@...mberg.me>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-fsdevel@...r.kernel.org, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf
On Thu, Jan 08, 2026 at 10:19:18AM +0800, Ming Lei wrote:
> > The feature is in no way nvme specific. nvme is just the initial
> > underlying driver. It makes total sense to support this for any high
> > performance block device, and to pass it through file systems.
>
> But why does FS care the dma buffer attachment? Since high performance
> host controller is exactly the dma buffer attachment point.
I can't parse what you're trying to say here.
> If the callback is added in `struct file_operations` for wiring dma buffer
> and the importer(host contrller), you will see it is hard to let it cross device
> mapper/raid or other stackable block devices.
Why?
But even when not stacking, the registration still needs to go
through the file system even for a single device, never mind multiple
controlled by the file system.
Powered by blists - more mailing lists