All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Sean Anderson <seanga2@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,
	Zhihao Cheng <chengzhihao1@huawei.com>
Subject: Re: bio segment constraints
Date: Mon, 7 Apr 2025 07:12:35 -0700	[thread overview]
Message-ID: <Z_PdU745eVHtwBER@infradead.org> (raw)
In-Reply-To: <28cd9608-5c62-7acc-ed52-41c9a74e8724@gmail.com>

On Mon, Apr 07, 2025 at 09:59:16AM -0400, Sean Anderson wrote:
> > drivers (case 1a), or generated by bio_split_to_limits (case 1b), which
> > is called for every blk-mq driver before calling into ->queue_rq(s) or
> > explicitly called by a few bio based driver.
> > 
> > The other is the bio-vec synthesized by bio_for_each_segment (case 2).
> 
> I'm referring to the bio_vecs you get from queue_mq. Which I think is the
> latter.

The bios hanging off the request have bio_vecs that are case 1b.

If you use bio_for_each_segment or an open coded variant of that on the
bio you get on-stack bio_vecs for case 2.

> > > - Is it possible to have a bio where the total length is a multiple of
> > >    logical_sector_size, but the data is split across several segments
> > >    where each segment is a multiple of SECTOR_SIZE?
> > 
> > Yes.
> 
> ...if this is the case, then for some of those segments wouldn't bv_len
> not be a multiple of logical_sector_size?

Maybe I'm misunderstanding the question.  But if you have e.g. a
transfer that is 2MiB, it could be perfectly fine that each bio_vec is
say 1kiB.

> > > - Can I somehow request to only get segments with bv_len aligned to
> > >    logical_sector_size?
> > 
> > For drivers that use bio_split_to_limits implicitly or explicitly you can
> > do that by setting the right seg_boundary_mask.
> 
> Is that the right knob? It operates on the physical address, so it looked
> more like something for broken DMA engines. For example (if I recall correctly)
> MMC SDMA can't cross a page boundary, so you could use seg_boundary_mask to
> enforce that.

seg_boundary_mask is indeed primarily about physical addresses.  That
being said if your seg_boundary_mask is logical_sector_size all bio_vecs
in cases 1a/b will be aligned to it for their base address, and thus
automatically their length too.

> > in the short run the best fix would be to synthesized a
> > bio_for_each_segment like bio_vec that stays inside a single page
> > using bio_iter_iovec) at the top of do_blktrans_request and use
> > that for all references to the data.
> > 
> 
> OK, but if you have to stay inside a single page couldn't you end up
> with a sector spanning a page boundary due to only being aligned to
> dma_alignment? Or maybe we set seg_boundary_mask to PAGE_MASK to enforce that?

bio_iter_iovec ensures that the synthetic request never crosses a
page boundary.  But as Keith pointed out that means if your
dma_alignment or seg_boundary_mask are smaller than the logical block
size you might actually get a non-aligned length.


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Sean Anderson <seanga2@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,
	Zhihao Cheng <chengzhihao1@huawei.com>
Subject: Re: bio segment constraints
Date: Mon, 7 Apr 2025 07:12:35 -0700	[thread overview]
Message-ID: <Z_PdU745eVHtwBER@infradead.org> (raw)
In-Reply-To: <28cd9608-5c62-7acc-ed52-41c9a74e8724@gmail.com>

On Mon, Apr 07, 2025 at 09:59:16AM -0400, Sean Anderson wrote:
> > drivers (case 1a), or generated by bio_split_to_limits (case 1b), which
> > is called for every blk-mq driver before calling into ->queue_rq(s) or
> > explicitly called by a few bio based driver.
> > 
> > The other is the bio-vec synthesized by bio_for_each_segment (case 2).
> 
> I'm referring to the bio_vecs you get from queue_mq. Which I think is the
> latter.

The bios hanging off the request have bio_vecs that are case 1b.

If you use bio_for_each_segment or an open coded variant of that on the
bio you get on-stack bio_vecs for case 2.

> > > - Is it possible to have a bio where the total length is a multiple of
> > >    logical_sector_size, but the data is split across several segments
> > >    where each segment is a multiple of SECTOR_SIZE?
> > 
> > Yes.
> 
> ...if this is the case, then for some of those segments wouldn't bv_len
> not be a multiple of logical_sector_size?

Maybe I'm misunderstanding the question.  But if you have e.g. a
transfer that is 2MiB, it could be perfectly fine that each bio_vec is
say 1kiB.

> > > - Can I somehow request to only get segments with bv_len aligned to
> > >    logical_sector_size?
> > 
> > For drivers that use bio_split_to_limits implicitly or explicitly you can
> > do that by setting the right seg_boundary_mask.
> 
> Is that the right knob? It operates on the physical address, so it looked
> more like something for broken DMA engines. For example (if I recall correctly)
> MMC SDMA can't cross a page boundary, so you could use seg_boundary_mask to
> enforce that.

seg_boundary_mask is indeed primarily about physical addresses.  That
being said if your seg_boundary_mask is logical_sector_size all bio_vecs
in cases 1a/b will be aligned to it for their base address, and thus
automatically their length too.

> > in the short run the best fix would be to synthesized a
> > bio_for_each_segment like bio_vec that stays inside a single page
> > using bio_iter_iovec) at the top of do_blktrans_request and use
> > that for all references to the data.
> > 
> 
> OK, but if you have to stay inside a single page couldn't you end up
> with a sector spanning a page boundary due to only being aligned to
> dma_alignment? Or maybe we set seg_boundary_mask to PAGE_MASK to enforce that?

bio_iter_iovec ensures that the synthetic request never crosses a
page boundary.  But as Keith pointed out that means if your
dma_alignment or seg_boundary_mask are smaller than the logical block
size you might actually get a non-aligned length.


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2025-04-07 14:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-06 19:40 bio segment constraints Sean Anderson
2025-04-06 19:40 ` Sean Anderson
2025-04-07  7:07 ` Christoph Hellwig
2025-04-07  7:07   ` Christoph Hellwig
2025-04-07 13:46   ` Keith Busch
2025-04-07 13:46     ` Keith Busch
2025-04-07 13:59     ` Christoph Hellwig
2025-04-07 13:59       ` Christoph Hellwig
2025-04-07 15:52       ` Bart Van Assche
2025-04-07 15:52         ` Bart Van Assche
2025-04-07 13:59   ` Sean Anderson
2025-04-07 13:59     ` Sean Anderson
2025-04-07 14:12     ` Christoph Hellwig [this message]
2025-04-07 14:12       ` Christoph Hellwig
2025-04-07  7:10 ` Hannes Reinecke
2025-04-07  7:10   ` Hannes Reinecke
2025-04-07 14:14   ` Sean Anderson
2025-04-07 14:14     ` Sean Anderson
2025-04-08  6:10     ` Hannes Reinecke
2025-04-08  6:10       ` Hannes Reinecke
2025-04-08 13:57       ` Sean Anderson
2025-04-08 13:57         ` Sean Anderson
2025-04-08 14:33     ` Keith Busch
2025-04-08 14:33       ` Keith Busch

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=Z_PdU745eVHtwBER@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=seanga2@gmail.com \
    --cc=vigneshr@ti.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.