Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2396918imu; Wed, 21 Nov 2018 10:59:46 -0800 (PST) X-Google-Smtp-Source: AJdET5fQ5dVUAfuxKCvwI2pxQrdmh8wS5vne2g9qrYaJ3DzEDKx5OxZ1uREdj2jWPNkm52JtJLv7 X-Received: by 2002:a62:5fc5:: with SMTP id t188-v6mr8116933pfb.84.1542826785988; Wed, 21 Nov 2018 10:59:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542826785; cv=none; d=google.com; s=arc-20160816; b=RSp6L5x3rfYis1r2pcXnkxbnjQRtuqsIzaOHx/cZzX/Q//fy3HFliTAm0aEqDNxc4B GJ2rXaVwWZ50QPSHH7TvP0xAU5xP9M4vV2n8J1wc7zqb8LQb8v6G8nTVsT0zZiMhjzwp FEmINHvikOcPvzBbvNNgnXppf3kFLHm+39AF0Y4boHYoO2tNl7hV81TyESol2HDwMyTY YQzlworYxayvex+PWoYWkrVVNP37mu3FnEgNDWAHy3GoVbFUIjig9LUbrzPzXuE8DZJk f6Dtw9IzVp6zqKT+zNUTYISJlDDP52/sT+Hf8B54veD+hGhu/r8fJveUzIfh2oP99m0S Bbig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uIiz7y/cE8tS3gZILHjj41+F/0ijn9yv0ziSOF9CTbc=; b=bvc6h/b2DtWBlaNusIVhKiOr1yE/U/vsojzNom/GPLJ3iAIKLyllqC1Tvu9cPyAkUM mNt7XoTGCxlPW93Acgam9/6zazorB8N7qQ3nsWxCgAZBpwtUdKwyft4HaDCV0UZyAWJh QNSWH0bR3c5c6ZMkUHT8enw5B1cRmO3p3KVwYKM1sv75SVLXEZZTNt+joh7SthUB+Z9j 6sLM+4G8JKtU2PsBGbF9jyQBhSFfadlDWR+sQdQLC424TJ44rrzc3ncwar5kBPGv+CaS dyeFmJP6+cRon5R178udzr5tDPtOiPV8AAkSvqdSRcnZS66yPix8TEImYSJxs83rYDmz 1IEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si48601458pla.2.2018.11.21.10.59.29; Wed, 21 Nov 2018 10:59:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731838AbeKVCpc (ORCPT + 99 others); Wed, 21 Nov 2018 21:45:32 -0500 Received: from verein.lst.de ([213.95.11.211]:52312 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730072AbeKVCpb (ORCPT ); Wed, 21 Nov 2018 21:45:31 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 9CF0768C19; Wed, 21 Nov 2018 17:10:25 +0100 (CET) Date: Wed, 21 Nov 2018 17:10:25 +0100 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o , Omar Sandoval , Sagi Grimberg , Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V11 03/19] block: introduce bio_for_each_bvec() Message-ID: <20181121161025.GB4977@lst.de> References: <20181121032327.8434-1-ming.lei@redhat.com> <20181121032327.8434-4-ming.lei@redhat.com> <20181121133244.GB1640@lst.de> <20181121153135.GB19111@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181121153135.GB19111@ming.t460p> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 21, 2018 at 11:31:36PM +0800, Ming Lei wrote: > > But while looking over this I wonder why we even need the max_seg_len > > here. The only thing __bvec_iter_advance does it to move bi_bvec_done > > and bi_idx forward, with corresponding decrements of bi_size. As far > > as I can tell the only thing that max_seg_len does is that we need > > to more iterations of the while loop to archive the same thing. > > > > And actual bvec used by the caller will be obtained using > > bvec_iter_bvec or segment_iter_bvec depending on if they want multi-page > > or single-page variants. > > Right, we let __bvec_iter_advance() serve for both multi-page and single-page > case, then we have to tell it via one way or another, now we use the constant > of 'max_seg_len'. > > Or you suggest to implement two versions of __bvec_iter_advance()? No - I think we can always use the code without any segment in bvec_iter_advance. Because bvec_iter_advance only operates on the iteractor, the generation of an actual single-page or multi-page bvec is left to the caller using the bvec_iter_bvec or segment_iter_bvec helpers. The only difference is how many bytes you can move the iterator forward in a single loop iteration - so if you pass in PAGE_SIZE as the max_seg_len you just will have to loop more often for a large enough bytes, but not actually do anything different.