On Tue, Sep 02, 2025 at 08:36:51AM -0600, Keith Busch wrote: > 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@xxxxxxxxxx> > > > > > > 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. Christoph, In addition, let's make sure that functionality is correct and working right. REQ_* cleanup can be perfect followup series for someone who understands semantics around these bits. Thanks
