From mboxrd@z Thu Jan 1 00:00:00 1970 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.subspace.kernel.org (Postfix) with ESMTPS id 4CE5370821 for ; Mon, 7 Apr 2025 14:12:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744035159; cv=none; b=Ec9fqTmmXb6kw+cUumMyZfy0ri2cLcQH75yUcXVfBoL+j6RvKb+Tsrf97L/no5kmLc0w1qFycpevONaPqAK1fB+Vx3OMr2AAsvS6wlZZh8m+xVmu8d9w8mDzezSh+Wq0sdxSrEZylMWnpfs6xRDAQu8CSd5gJ7sHbtpJcQwfz6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744035159; c=relaxed/simple; bh=GvPIfJrbySPAH/VFQzxQC54nqxhI6zkOK7Pvg1D/WcI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WOcIBJzqQdOI6wSvTuq0WLtkcX7av9163ldAwlFXULYjQMACOEG/pOc6fWP3KPZjNGct8GglI3rKigTbl8e/H25OavkpQesuA8ntbPT8FxFSrKrA6LuOgHWtQRD0kUUFR7k/S4UrFe8j3S+wnimMFY6HeUgHTthjogL1eHgb1IY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=h+pLczR/; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="h+pLczR/" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EsY1u/F1AZkq/Gsge9DhXDZ7a+2BXj1x0L7mEP0iAEE=; b=h+pLczR/9L2wdmPgK71KXFNWUz tWmA8ptHU82WTUx+Qh211RaMj05DET6a9rKdYf08+9tvgbcUvY+a/RnDK3TcqGE3QtmvW76Iaptlu /+YuIivcC9Cbe0OEmdyTxK1buZMIJ3613gBTRCB7CixzFbjWkh7SHGUBUI+27aZTo92+S+D4WMJLt 1C4Xz8ASw28Opdq9X6S06R07v/QuRkSn9Wu+/6w/sFbbrK0ig2qQYVzGo8i6wY2HMBIsr34eMgF3T dCAVjUXgD8JoDgVd4X59S82+69IepZfttmb/9QF6sef9jlL8FNqdHa1zbJ1c3gEjX2wlHxSYQYLvy S0OxzRng==; 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> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28cd9608-5c62-7acc-ed52-41c9a74e8724@gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html 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.