Re: [PATCH] nvme: uring_cmd specific request_queue for SGLs

[Christoph Hellwig <hch@lst.de>]

On Thu, Jun 26, 2025 at 09:29:21AM -0600, Keith Busch wrote:
> > I can't really parse this.  Direct mapping means not using an IOMMU
> > mapping, either because there is none or because it is configured to
> > do an identity mapping.  In that case we'll never use the IOVA path.
> 
> Okay, maybe I'm confused. The code looks like it defaults to the direct
> mapping if it can't be coalesced.

Oh, you are referring to blk_dma_map_direct?  I guess that is a bit
misnamed, as it doesn't mean we're doing the dma-level concept of a
direct mapping, but anything that is not an iova-based coalesce
operation.

> What if the IOMMU granularity is 8k against nvme's 4k virt boundary?

Then we won't merge.  Note that most (maybe even all) relevant IOMMUs
support 4k mappings, including for system that have larger IOMMU page
sizes.

> We still need the IOMMU dma mappings in
> the direct mapping fallback, right? They should just appear as different
> dma segments.



> When it comes to integrity payloads, merged bio's are almost certainly
> not eligible to be coalesced in iova space since they're usually
> independently allocated in much smaller granularities, so again, I'd
> expect we'd get multiple integrity dma segments.

For the current user DMA that depends on how how user allocated it,
but unless they nicely chunk it up based on the IOMMIU page size: yes.

But when merging multiple bios with the block layer default integrity we
can get it now with the right max_sectors, and the same will
usually/always be true for the file system integrity work in progress.