Re: [PATCH v4 08/14] nvme-pci: implement dma_token backed requests

Anuj Gupta/Anuj Gupta <[email protected]>
Newsgroups org.kernel.vger.linux-media,dev.linux.lists.dm-devel,dev.linux.lists.nvdimm,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-nvme,org.kernel.vger.ceph-devel,org.kernel.vger.io-uring,org.kernel.vger.linux-block,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/30/2026 4:11 PM, Pavel Begunkov wrote:
>>
>> I wonder if it's possible to perform the PRP list page allocations and
>> initialization in nvme_dma_buf_io_map() instead of the I/O path. The
>> NVMe dma_pools are per-NUMA-node linked lists protected by spinlocks,
>> making them significant CPU hotspots. If the dmabuf registration set
>> up a contiguous DMA-coherent list of PRP entries for the pages of the
>> registered buffer, any command using the dmabuf and requiring at most
>> 1 PRP list page (i.e. length <= 2 MB) could just set its PRP list
>> pointer to an offset into the dmabuf's PRP list.
> 
> Possible to an extent, predecessor patches tried that, I left it for
> later to keep the series simpler. I guess chaining won't work in
> general case.
> I mentioned this to Kanchan, Anuj and Nitesh before, they were up to
> playing with nvme optimisations in general, and since sgl from Anuj
> is ready, maybe they already have a prototype somewhere for that.
> 

Right, I have prototyped the PRP list optimisation before. I will send 
it once the initial version of this series lands, to avoid adding new 
review churn while the rest of the series is pretty settled.
> -- 
> Pavel Begunkov
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.