Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp109316pxu; Tue, 5 Jan 2021 06:29:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJwV//fbEiUvnKnSjeQg3ax6h+WMPP3s5dGF16+o5xIfkTZrGNq3LD58yfOqEK5+CT6/2RUb X-Received: by 2002:a05:6402:100c:: with SMTP id c12mr78724482edu.356.1609856957236; Tue, 05 Jan 2021 06:29:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609856957; cv=none; d=google.com; s=arc-20160816; b=Z8blTNFQiAZdmuxzjdi5RKjaG47l6oqwt7Lb0AtxwueIBiC65WVY86tCkkl5/iUxCL 7zivebZgW+tIUidU2VXO46Uezmjwb2alT6KAogvcf9ssewF8fvEFNCXSHwdIr/QWVLN1 S6Jpb4lChjnTcSvLnrDdvesTTXb8GNxpxxcx4v1Y1RmE50+upckscSkaKvGZYti2K4kT wlxOcsMPJAVbLEZ6elQoWq9PZFCHmDUObhepNcVB0DQ94Fya/6Ln1LSle+bOQc2XTkCm p0p0n/YOjrnVK7MKy7XP3sLQsCLIoKUDzvNp4r4qu4m4EpAH21/FipZCbeWcLcjKjvTy xbNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=j1NvKmtJGKiFDjjXKZ0rVwy5v3Z3i/GAMZvpNKKRLfc=; b=HTrzJ1dYQMMLVvxaPyRBRPN97N9Nc56ijMzo+4pgaMuQQrlBrPBBzL9oNtxU6pEu+n eBzI0mIXfSDbgrH0YeWlcvhxNcT0PDJo1Q7Lypjky6bCQO9Fm/MPtXaan8aWjzhA/O9g 6+vF/W4gI2R2kLqmerhQ6lMo1orQIoar0z4pX9UVww7rm1vaqoxtbSJ7yMNQpdyQRXi1 EOFaxZawRu5AoBHxeDH44o/G2iVU1aHN5CPxnOjU/WJ7xfZu5JSJKYCGn+8J+Mut/7kN yM/wajzytB6sD8h3j/D33N1yzI4xb6Kt3TdOCdHN1l7RfMj5TRlW7c7RO4W9a/uj34j7 eFPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M65TtKlK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v29si33604253edi.58.2021.01.05.06.28.41; Tue, 05 Jan 2021 06:29:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M65TtKlK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727410AbhAEOXo (ORCPT + 99 others); Tue, 5 Jan 2021 09:23:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726600AbhAEOXn (ORCPT ); Tue, 5 Jan 2021 09:23:43 -0500 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 482BBC061574; Tue, 5 Jan 2021 06:23:03 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id ga15so9284516ejb.4; Tue, 05 Jan 2021 06:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j1NvKmtJGKiFDjjXKZ0rVwy5v3Z3i/GAMZvpNKKRLfc=; b=M65TtKlKHGtX8mX+g+91fAHKCph41gARK7tY21v1oWRfOglc1+76okSjorE6vtFjMx JJbVrreafdRsihFtWoQGrxaLull4FcSN/9QzVSNHuujlY44q+OxDDxkKdAM1QqMibP0n Pk6wBiWKF9Ss8SUk3mC+r4uoQTFT3T9wuN5mMezTf6gMhehl8AX51wQMFk07WoHUBSuY VOzA7W/vIx0lbkqw9RcwNVYhqWZryiE2gDiKn5bICDNMb2EuBEk6Jh7EJxenAlVDegp2 E5VQLDbhdXKMkXaCv7yoWgmO6MIVVkXzQiWe8eXaV88qIR2L7UUwO6E1t+V9DFExVU9d HbhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=j1NvKmtJGKiFDjjXKZ0rVwy5v3Z3i/GAMZvpNKKRLfc=; b=Mu7MGNxNxBT3nnkIexpzYCORuRRqU/XnBtXp+irEBEjqCqzUlXz4ky1QG64cQ/XbsT y6U+fcrq37SfpdBNBmz0cAI7+D0lnmrRiJbuPa2tMJ6lHxxrj148WM/X3KcgjwVMQ6Se PV9/5Sd3jeZ8E1LoNqBms7OeZGSXzK3IdbYR9KdZO02DM6Qr9e2CKQHTbwxr7iIPyGhr EYKq+2kMaDNpAQMBCNeam8ec9uaBbvy7XHA8Mcxmofw77jTLSnzHQgXJQgm4i2IRndrF qJInquACddL/JLQAs9sNQ+WISShNv3IWYvMh6EeKcvCjHl0V9A52GfIxKGM3oXQCl2XM +wyQ== X-Gm-Message-State: AOAM532fnFrLK5gBIDZ17nkYJ0+WAYtB4dnTIZ4lbiHPcVMD05ahsgqk ptRgcgC0l32bsG7S9Emc7RCgTqox8Ww7QqnEymE= X-Received: by 2002:a17:907:271c:: with SMTP id w28mr70922796ejk.140.1609856581820; Tue, 05 Jan 2021 06:23:01 -0800 (PST) MIME-Version: 1.0 References: <20210104104159.74236-1-selvakuma.s1@samsung.com> <20210104104159.74236-3-selvakuma.s1@samsung.com> <20210104190254.GB6919@magnolia> In-Reply-To: <20210104190254.GB6919@magnolia> From: Selva Jove Date: Tue, 5 Jan 2021 19:52:48 +0530 Message-ID: Subject: Re: [dm-devel] [RFC PATCH v4 2/3] block: add simple copy support To: "Darrick J. Wong" Cc: Damien Le Moal , SelvaKumar S , "linux-nvme@lists.infradead.org" , "axboe@kernel.dk" , "sagi@grimberg.me" , "linux-scsi@vger.kernel.org" , Johannes Thumshirn , "snitzer@redhat.com" , "linux-kernel@vger.kernel.org" , "nj.shetty@samsung.com" , "linux-block@vger.kernel.org" , "dm-devel@redhat.com" , "mpatocka@redhat.com" , "joshi.k@samsung.com" , "martin.petersen@oracle.com" , "kbusch@kernel.org" , "javier.gonz@samsung.com" , "hch@lst.de" , "bvanassche@acm.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Darrick, On Tue, Jan 5, 2021 at 12:33 AM Darrick J. Wong w= rote: > > SelvaKumar S: This didn't show up on dm-devel, sorry for the OT reply... > > On Mon, Jan 04, 2021 at 12:47:11PM +0000, Damien Le Moal wrote: > > On 2021/01/04 19:48, SelvaKumar S wrote: > > > Add new BLKCOPY ioctl that offloads copying of one or more sources > > > ranges to a destination in the device. Accepts copy_ranges that conta= ins > > > destination, no of sources and pointer to the array of source > > > ranges. Each range_entry contains start and length of source > > > ranges (in bytes). > > > > > > Introduce REQ_OP_COPY, a no-merge copy offload operation. Create > > > bio with control information as payload and submit to the device. > > > REQ_OP_COPY(19) is a write op and takes zone_write_lock when submitte= d > > > to zoned device. > > > > > > If the device doesn't support copy or copy offload is disabled, then > > > copy is emulated by allocating memory of total copy size. The source > > > ranges are read into memory by chaining bio for each source ranges an= d > > > submitting them async and the last bio waits for completion. After da= ta > > > is read, it is written to the destination. > > > > > > bio_map_kern() is used to allocate bio and add pages of copy buffer t= o > > > bio. As bio->bi_private and bio->bi_end_io is needed for chaining the > > > bio and over written, invalidate_kernel_vmap_range() for read is call= ed > > > in the caller. > > > > > > Introduce queue limits for simple copy and other helper functions. > > > Add device limits as sysfs entries. > > > - copy_offload > > > - max_copy_sectors > > > - max_copy_ranges_sectors > > > - max_copy_nr_ranges > > > > > > copy_offload(=3D 0) is disabled by default. > > > max_copy_sectors =3D 0 indicates the device doesn't support native co= py. > > > > > > Native copy offload is not supported for stacked devices and is done = via > > > copy emulation. > > > > > > Signed-off-by: SelvaKumar S > > > Signed-off-by: Kanchan Joshi > > > Signed-off-by: Nitesh Shetty > > > Signed-off-by: Javier Gonz=C3=A1lez > > > --- > > > block/blk-core.c | 94 ++++++++++++++-- > > > block/blk-lib.c | 223 ++++++++++++++++++++++++++++++++++++= ++ > > > block/blk-merge.c | 2 + > > > block/blk-settings.c | 10 ++ > > > block/blk-sysfs.c | 50 +++++++++ > > > block/blk-zoned.c | 1 + > > > block/bounce.c | 1 + > > > block/ioctl.c | 43 ++++++++ > > > include/linux/bio.h | 1 + > > > include/linux/blk_types.h | 15 +++ > > > include/linux/blkdev.h | 13 +++ > > > include/uapi/linux/fs.h | 13 +++ > > This series should also be cc'd to linux-api since you're adding a new > userspace api. > Sure. Will cc linux-api > > Alternately, save yourself the trouble of passing userspace API review > by hooking this up to the existing copy_file_range call in the vfs. /me > hopes you sent blktests to check the operation of this thing, since none > of the original patches made it to this list. > As the initial version had only source bdev, copy_file_rage call was not viable. With this version, we have two bdev for source and destination. I'll relook at that. Sure. Will add a new blktests for simple copy. > > If you really /do/ need a new kernel call for this, then please send in > a manpage documenting the fields of struct range_entry and copy_range, > and how users are supposed to use this. > Sure. Will send a manpage documentation once the plumbing is concrete. > plumbing...> > > > > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h > > > index f44eb0a04afd..5cadb176317a 100644 > > > --- a/include/uapi/linux/fs.h > > > +++ b/include/uapi/linux/fs.h > > > @@ -64,6 +64,18 @@ struct fstrim_range { > > > __u64 minlen; > > > }; > > > > > > +struct range_entry { > > > + __u64 src; > > Is this an offset? Or the fd of an open bdev? This is the source offset. > > > > + __u64 len; > > > +}; > > > + > > > +struct copy_range { > > > + __u64 dest; > > > + __u64 nr_range; > > > + __u64 range_list; > > Hm, I think this is a pointer? Why not just put the range_entry array > at the end of struct copy_range? > As the size of the range_entry array can change dynamically depending on nr_range, it was difficult to do copy_from_user() on copy_range structure i= n the ioctl. So I decided to keep that as a pointer to range_entry array instead of keeping array at the end. > > > + __u64 rsvd; > > Also needs a flags argument so we don't have to add BLKCOPY2 in like 3 > months. > 'rsvd' field is kept to support future copies. Will rename it. > --D > > > > +}; > > > + > > > /* extent-same (dedupe) ioctls; these MUST match the btrfs ioctl def= initions */ > > > #define FILE_DEDUPE_RANGE_SAME 0 > > > #define FILE_DEDUPE_RANGE_DIFFERS 1 > > > @@ -184,6 +196,7 @@ struct fsxattr { > > > #define BLKSECDISCARD _IO(0x12,125) > > > #define BLKROTATIONAL _IO(0x12,126) > > > #define BLKZEROOUT _IO(0x12,127) > > > +#define BLKCOPY _IOWR(0x12, 128, struct copy_range) > > > /* > > > * A jump here: 130-131 are reserved for zoned block devices > > > * (see uapi/linux/blkzoned.h) > > > > > > > > > -- > > Damien Le Moal > > Western Digital Research > > > > > > > > -- > > dm-devel mailing list > > dm-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/dm-devel > > Thanks, Selva