[PATCH 2/2] blk-mq-dma: bring back p2p request flags

[Keith Busch]

On Tue, Sep 02, 2025 at 07:33:58AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 29, 2025 at 07:23:07AM -0700, Keith Busch wrote:
> > From: Keith Busch <kbusch at kernel.org>
> > 
> > We only need to consider data and metadata dma mapping types separately.
> > The request and bio integrity payload have enough flag bits to
> > internally track the mapping type for each. Add flags for these so the
> > caller doesn't need to track them, and provide separete request and
> > integrity helpers to the common code for unmpaping. This will make it
> > easier to scale as new mappings are added without burdening the caller
> > to track such things.
> 
> We are actually about to run out of REQ_* bits with the current
> encoding.  We could shrink the space for REQ_OP_ a bit to create
> more, or try to move some flags out into BIO_ flags (like
> REQ_ALLOC_CACHE) or kill them by looking at pointers instead
> (REQ_INTEGRITY), or by overlaying flags that can't be used with
> the same of (REQ_FUA vs REQ_RAHEAD vs REQ_UNMAP for example).
> And maybe we can come up with a more coherent scheme for
> REQ_PRIO / REQ_BACKGROUND / REQ_SWAP and maybe REQ_IDLE that create
> another priority scheme in addition to the I/O priorities.
 
Sure, but can we do that effort separately from this? I'm mainly trying
to align with Leon's DMA series that adds REQ_MMIO so that we won't have
flag conflicts.