Re: [PATCH v20 12/12] null_blk: add support for copy offload
From: Nitesh Shetty <hidden>
Date: 2024-05-23 07:18:58
Also in:
dm-devel, linux-doc, linux-fsdevel, linux-nvme, lkml
From: Nitesh Shetty <hidden>
Date: 2024-05-23 07:18:58
Also in:
dm-devel, linux-doc, linux-fsdevel, linux-nvme, lkml
On 22/05/24 10:52AM, Bart Van Assche wrote:
On 5/21/24 07:46, Nitesh Shetty wrote:quoted
On 20/05/24 04:42PM, Bart Van Assche wrote:quoted
On 5/20/24 03:20, Nitesh Shetty wrote:quoted
+ __rq_for_each_bio(bio, req) { + if (seg == blk_rq_nr_phys_segments(req)) { + sector_in = bio->bi_iter.bi_sector; + if (rem != bio->bi_iter.bi_size) + return status; + } else { + sector_out = bio->bi_iter.bi_sector; + rem = bio->bi_iter.bi_size; + } + seg++; + }_rq_for_each_bio() iterates over the bios in a request. Does a copy offload request always have two bios - one copy destination bio and one copy source bio? If so, is 'seg' a bio counter? Why is that bio counter compared with the number of physical segments in the request?Yes, your observation is right. We are treating first bio as dst and second as src. If not for that comparision, we might need to store the index in a temporary variable and parse based on index value.I'm still wondering why 'seg' is compared with blk_rq_nr_phys_segments(req).
In this case blk_rq_nr_phys_segments is used as counter value(==2), which tells its a src IO. But using a macro instead of this comparison will avoid this confusion. We will change this in next version to make it explicit. Thank you, Nitesh Shetty