All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
	axboe@kernel.dk, martin.petersen@oracle.com, jgg@nvidia.com,
	leon@kernel.org
Subject: Re: [PATCH 2/2] blk-mq-dma: bring back p2p request flags
Date: Tue, 2 Sep 2025 16:54:09 +0200	[thread overview]
Message-ID: <20250902145409.GA13103@lst.de> (raw)
In-Reply-To: <aLcBA-Z8yZ44t4ZK@kbusch-mbp>

On Tue, Sep 02, 2025 at 08:36:51AM -0600, Keith Busch wrote:
> > 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.

I was just thinking out aloud how we could reclaim them, not trying
to take that on for this series.

  reply	other threads:[~2025-09-02 14:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 14:23 [PATCH 0/2] blk-mq-dma: p2p cleanups and integrity fixup Keith Busch
2025-08-29 14:23 ` [PATCH 1/2] blk-integrity: enable p2p source and destination Keith Busch
2025-09-02  5:27   ` Christoph Hellwig
2025-08-29 14:23 ` [PATCH 2/2] blk-mq-dma: bring back p2p request flags Keith Busch
2025-08-29 15:15   ` Keith Busch
2025-09-02  5:33   ` Christoph Hellwig
2025-09-02 14:36     ` Keith Busch
2025-09-02 14:54       ` Christoph Hellwig [this message]
2025-09-02 14:57       ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250902145409.GA13103@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=jgg@nvidia.com \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=leon@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.