From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 27717C3601E for ; Mon, 7 Apr 2025 16:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZYJiF4DTYHsQW91Sm7vLMr9b8u2qhQSYSHrxfqYoe1E=; b=KjaMKfY0yQiLC/ vMxDrlAC6LCGYgFSWH1n5J7zzorHj3qbh5csAVa1hGoros4s40c9G0q8iNPQSWz5y5xnP4uC5jUoy 9hSw9K0WwtNmRDg1guv+FDN4RHk6xtSsPAhIaXXIsidxptOgUHU02Kxbvzl//9cWP6LupSpk1dWlX 02eysBhHPBXYuIFgoAPJqqSI3QMsn2r7jdlyvixjIxDCj9SAUzXch8piL9q6ZmRHLaSOxVJxQu4TZ JBLxFcOcWC66tzoXmlhhnTdtmqMEk7jwzdzDF9uei4Z99MwTRdQGImCy76/hVpho0NveVYheLXt49 eNXIdDe+sNft4TSR/FTQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1u1oxn-000000013Hm-0Dig; Mon, 07 Apr 2025 16:04:43 +0000 Received: from hch by bombadil.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1u1nDH-00000000ftI-2NIs; Mon, 07 Apr 2025 14:12:35 +0000 Date: Mon, 7 Apr 2025 07:12:35 -0700 From: Christoph Hellwig To: Sean Anderson Cc: Christoph Hellwig , Jens Axboe , linux-block@vger.kernel.org, Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, Zhihao Cheng Subject: Re: bio segment constraints Message-ID: References: <8dfd97ac-59e7-ae69-238a-85b7a2dae4f1@gmail.com> <28cd9608-5c62-7acc-ed52-41c9a74e8724@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <28cd9608-5c62-7acc-ed52-41c9a74e8724@gmail.com> X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org 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/