On Wed, Nov 21, 2018 at 05:10:25PM +0100, Christoph Hellwig wrote: > 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. Yeah, I see that. The difference is made by bio_iter_iovec()/bio_iter_mp_iovec() in __bio_for_each_segment()/__bio_for_each_bvec(). Thanks, Ming -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
