Re: [PATCH v20 12/12] null_blk: add support for copy offload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/21/24 07:46, Nitesh Shetty wrote:
On 20/05/24 04:42PM, Bart Van Assche wrote:
On 5/20/24 03:20, Nitesh Shetty wrote:
+    __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).

Thanks,

Bart.






[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux