All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sean Anderson <seanga2@gmail.com>, 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 14:46:32 +0100	[thread overview]
Message-ID: <Z_PXONJyuv4Z8ATr@kbusch-mbp> (raw)
In-Reply-To: <Z_N5nxLDOBb5NDAM@infradead.org>

On Mon, Apr 07, 2025 at 12:07:11AM -0700, Christoph Hellwig wrote:
> On Sun, Apr 06, 2025 at 03:40:04PM -0400, Sean Anderson wrote:
> > - What about bv_offset?
> 
> bv_offset is a memory offset and must only be aligned to the
> dma_alignment limit.
> 
> > - 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.
> 
> > - Is is possible to have segments not even aligned to SECTOR_SIZE?
> 
> No.

O_DIRECT only requires each user iovec be a multiple of the logical
block size with the address aligned to the dma_alignment. If the
dma_alignment is smaller than the logical block size, then this could
create bvec segments that are smaller. For nvme where we have 4-byte
dma alignment, you could have the first segment be the last 4 bytes of a
page, then the remaing 508 bytes from a different page in the next
segment.

WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sean Anderson <seanga2@gmail.com>, 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 14:46:32 +0100	[thread overview]
Message-ID: <Z_PXONJyuv4Z8ATr@kbusch-mbp> (raw)
In-Reply-To: <Z_N5nxLDOBb5NDAM@infradead.org>

On Mon, Apr 07, 2025 at 12:07:11AM -0700, Christoph Hellwig wrote:
> On Sun, Apr 06, 2025 at 03:40:04PM -0400, Sean Anderson wrote:
> > - What about bv_offset?
> 
> bv_offset is a memory offset and must only be aligned to the
> dma_alignment limit.
> 
> > - 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.
> 
> > - Is is possible to have segments not even aligned to SECTOR_SIZE?
> 
> No.

O_DIRECT only requires each user iovec be a multiple of the logical
block size with the address aligned to the dma_alignment. If the
dma_alignment is smaller than the logical block size, then this could
create bvec segments that are smaller. For nvme where we have 4-byte
dma alignment, you could have the first segment be the last 4 bytes of a
page, then the remaing 508 bytes from a different page in the next
segment.

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

  reply	other threads:[~2025-04-07 13:46 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 [this message]
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
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_PXONJyuv4Z8ATr@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=chengzhihao1@huawei.com \
    --cc=hch@infradead.org \
    --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.