From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Nitesh Shetty <nj.shetty@samsung.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
dm-devel@redhat.com, linux-nvme@lists.infradead.org,
linux-fsdevel@vger.kernel.org, nitheshshetty@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 02/10] block: Add copy offload support infrastructure
Date: Thu, 28 Apr 2022 07:04:13 +0900 [thread overview]
Message-ID: <0d3b0a6b-825d-1b01-094a-911f81f5f354@opensource.wdc.com> (raw)
In-Reply-To: <20220427151535.GC9558@test-zns>
On 4/28/22 00:15, Nitesh Shetty wrote:
> On Wed, Apr 27, 2022 at 11:45:26AM +0900, Damien Le Moal wrote:
>> On 4/26/22 19:12, Nitesh Shetty wrote:
>>> Introduce blkdev_issue_copy which supports source and destination bdevs,
>>> and an array of (source, destination and copy length) tuples.
>>> Introduce REQ_COPY copy offload operation flag. Create a read-write
>>> bio pair with a token as payload and submitted to the device in order.
>>> Read request populates token with source specific information which
>>> is then passed with write request.
>>> This design is courtesy Mikulas Patocka's token based copy
>>>
>>> Larger copy will be divided, based on max_copy_sectors,
>>> max_copy_range_sector limits.
>>>
>>> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
>>> Signed-off-by: Arnav Dawn <arnav.dawn@samsung.com>
>>> ---
>>> block/blk-lib.c | 232 ++++++++++++++++++++++++++++++++++++++
>>> block/blk.h | 2 +
>>> include/linux/blk_types.h | 21 ++++
>>> include/linux/blkdev.h | 2 +
>>> include/uapi/linux/fs.h | 14 +++
>>> 5 files changed, 271 insertions(+)
>>>
>>> diff --git a/block/blk-lib.c b/block/blk-lib.c
>>> index 09b7e1200c0f..ba9da2d2f429 100644
>>> --- a/block/blk-lib.c
>>> +++ b/block/blk-lib.c
>>> @@ -117,6 +117,238 @@ int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
>>> }
>>> EXPORT_SYMBOL(blkdev_issue_discard);
>>>
>>> +/*
>>> + * Wait on and process all in-flight BIOs. This must only be called once
>>> + * all bios have been issued so that the refcount can only decrease.
>>> + * This just waits for all bios to make it through bio_copy_end_io. IO
>>> + * errors are propagated through cio->io_error.
>>> + */
>>> +static int cio_await_completion(struct cio *cio)
>>> +{
>>> + int ret = 0;
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(&cio->lock, flags);
>>> + if (cio->refcount) {
>>> + cio->waiter = current;
>>> + __set_current_state(TASK_UNINTERRUPTIBLE);
>>> + spin_unlock_irqrestore(&cio->lock, flags);
>>> + blk_io_schedule();
>>> + /* wake up sets us TASK_RUNNING */
>>> + spin_lock_irqsave(&cio->lock, flags);
>>> + cio->waiter = NULL;
>>> + ret = cio->io_err;
>>> + }
>>> + spin_unlock_irqrestore(&cio->lock, flags);
>>> + kvfree(cio);
>>
>> cio is allocated with kzalloc() == kmalloc(). So why the kvfree() here ?
>>
>
> acked.
>
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static void bio_copy_end_io(struct bio *bio)
>>> +{
>>> + struct copy_ctx *ctx = bio->bi_private;
>>> + struct cio *cio = ctx->cio;
>>> + sector_t clen;
>>> + int ri = ctx->range_idx;
>>> + unsigned long flags;
>>> + bool wake = false;
>>> +
>>> + if (bio->bi_status) {
>>> + cio->io_err = bio->bi_status;
>>> + clen = (bio->bi_iter.bi_sector << SECTOR_SHIFT) - ctx->start_sec;
>>> + cio->rlist[ri].comp_len = min_t(sector_t, clen, cio->rlist[ri].comp_len);
>>
>> long line.
>
> Is it because line is more than 80 character, I thought limit is 100 now, so
> went with longer lines ?
When it is easy to wrap the lines without readability loss, please do to
keep things under 80 char per line.
>>> +{
>>> + struct request_queue *src_q = bdev_get_queue(src_bdev);
>>> + struct request_queue *dest_q = bdev_get_queue(dest_bdev);
>>> + int ret = -EINVAL;
>>> +
>>> + if (!src_q || !dest_q)
>>> + return -ENXIO;
>>> +
>>> + if (!nr)
>>> + return -EINVAL;
>>> +
>>> + if (nr >= MAX_COPY_NR_RANGE)
>>> + return -EINVAL;
>>
>> Where do you check the number of ranges against what the device can do ?
>>
>
> The present implementation submits only one range at a time. This was done to
> make copy offload generic, so that other types of copy implementation such as
> XCOPY should be able to use same infrastructure. Downside at present being
> NVMe copy offload is not optimal.
If you issue one range at a time without checking the number of ranges,
what is the point of the nr ranges queue limit ? The user can submit a
copy ioctl request exceeding it. Please use that limit and enforce it or
remove it entirely.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-04-27 22:04 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220426101804epcas5p4a0a325d3ce89e868e4924bbdeeba6d15@epcas5p4.samsung.com>
2022-04-26 10:12 ` [PATCH v4 00/10] Add Copy offload support Nitesh Shetty
[not found] ` <CGME20220426101910epcas5p4fd64f83c6da9bbd891107d158a2743b5@epcas5p4.samsung.com>
2022-04-26 10:12 ` [PATCH v4 01/10] block: Introduce queue limits for copy-offload support Nitesh Shetty
2022-04-27 1:59 ` Damien Le Moal
2022-04-27 15:30 ` Nitesh Shetty
2022-04-27 21:57 ` Damien Le Moal
2022-04-27 10:30 ` Hannes Reinecke
[not found] ` <CGME20220426101921epcas5p341707619b5e836490284a42c92762083@epcas5p3.samsung.com>
2022-04-26 10:12 ` [PATCH v4 02/10] block: Add copy offload support infrastructure Nitesh Shetty
2022-04-27 0:11 ` kernel test robot
2022-04-27 2:45 ` Damien Le Moal
2022-04-27 15:15 ` Nitesh Shetty
2022-04-27 22:04 ` Damien Le Moal [this message]
2022-04-28 8:01 ` Nitesh Shetty
2022-04-27 10:29 ` Hannes Reinecke
2022-04-27 15:48 ` Nitesh Shetty
[not found] ` <CGME20220426101938epcas5p291690dd1f0e931cd9f8139daaf3f9296@epcas5p2.samsung.com>
2022-04-26 10:12 ` [PATCH v4 03/10] block: Introduce a new ioctl for copy Nitesh Shetty
2022-04-27 2:48 ` Damien Le Moal
2022-04-27 13:03 ` Nitesh Shetty
2022-04-27 10:37 ` Hannes Reinecke
[not found] ` <CGME20220426101951epcas5p1f53a2120010607354dc29bf8331f6af8@epcas5p1.samsung.com>
2022-04-26 10:12 ` [PATCH v4 04/10] block: add emulation " Nitesh Shetty
2022-04-27 1:33 ` kernel test robot
[not found] ` <CGME20220426102001epcas5p4e321347334971d704cb19ffa25f9d0b4@epcas5p4.samsung.com>
2022-04-26 10:12 ` [PATCH v4 05/10] nvme: add copy offload support Nitesh Shetty
2022-04-28 14:02 ` kernel test robot
[not found] ` <CGME20220426102009epcas5p3e5b1ddfd5d3c7200972cecb139650da6@epcas5p3.samsung.com>
2022-04-26 10:12 ` [PATCH v4 06/10] nvmet: add copy command support for bdev and file ns Nitesh Shetty
2022-04-28 14:53 ` kernel test robot
[not found] ` <CGME20220426102017epcas5p295d3b62eaa250765e48c767962cbf08b@epcas5p2.samsung.com>
2022-04-26 10:12 ` [PATCH v4 07/10] dm: Add support for copy offload Nitesh Shetty
2022-04-28 15:54 ` kernel test robot
[not found] ` <CGME20220426102025epcas5p299d9a88c30db8b9a04a05c57dc809ff7@epcas5p2.samsung.com>
2022-04-26 10:12 ` [PATCH v4 08/10] dm: Enable copy offload for dm-linear target Nitesh Shetty
[not found] ` <CGME20220426102033epcas5p137171ff842e8b0a090d2708cfc0e3249@epcas5p1.samsung.com>
2022-04-26 10:12 ` [PATCH v4 09/10] dm kcopyd: use copy offload support Nitesh Shetty
[not found] ` <CGME20220426102042epcas5p201aa0d9143d7bc650ae7858383b69288@epcas5p2.samsung.com>
2022-04-26 10:12 ` [PATCH v4 10/10] fs: add support for copy file range in zonefs Nitesh Shetty
2022-04-27 1:42 ` Damien Le Moal
2022-04-27 1:46 ` [PATCH v4 00/10] Add Copy offload support Damien Le Moal
2022-04-27 15:38 ` Nitesh Shetty
2022-04-27 21:56 ` Damien Le Moal
2022-04-27 2:00 ` Damien Le Moal
2022-04-27 2:19 ` Damien Le Moal
2022-04-27 12:49 ` Nitesh Shetty
2022-04-27 22:05 ` Damien Le Moal
2022-04-28 7:49 ` Nitesh Shetty
2022-04-28 21:37 ` Damien Le Moal
2022-04-29 3:39 ` [dm-devel] " Bart Van Assche
2022-05-02 4:09 ` Dave Chinner
2022-05-02 12:54 ` Damien Le Moal
2022-05-02 23:20 ` Dave Chinner
2022-05-02 12:14 ` [dm-devel] " Damien Le Moal
2022-05-02 12:16 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d3b0a6b-825d-1b01-094a-911f81f5f354@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nitheshshetty@gmail.com \
--cc=nj.shetty@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).