From: Damien Le Moal <damien.lemoal@opensource.wdc.com> To: Anuj Gupta <anuj20.g@samsung.com>, Jens Axboe <axboe@kernel.dk>, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com, Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>, James Smart <james.smart@broadcom.com>, Chaitanya Kulkarni <kch@nvidia.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org> Cc: bvanassche@acm.org, hare@suse.de, ming.lei@redhat.com, joshi.k@samsung.com, nitheshshetty@gmail.com, gost.dev@samsung.com, Nitesh Shetty <nj.shetty@samsung.com>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v8 1/9] block: Introduce queue limits for copy-offload support Date: Wed, 29 Mar 2023 17:40:09 +0900 [thread overview] Message-ID: <e725768d-19f5-a78a-2b05-c0b189624fea@opensource.wdc.com> (raw) In-Reply-To: <20230327084103.21601-2-anuj20.g@samsung.com> On 3/27/23 17:40, Anuj Gupta wrote: > From: Nitesh Shetty <nj.shetty@samsung.com> > > Add device limits as sysfs entries, > - copy_offload (RW) > - copy_max_bytes (RW) > - copy_max_bytes_hw (RO) > > Above limits help to split the copy payload in block layer. > copy_offload: used for setting copy offload(1) or emulation(0). > copy_max_bytes: maximum total length of copy in single payload. > copy_max_bytes_hw: Reflects the device supported maximum limit. > > Reviewed-by: Hannes Reinecke <hare@suse.de> > Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> > Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> > Signed-off-by: Anuj Gupta <anuj20.g@samsung.com> > --- > Documentation/ABI/stable/sysfs-block | 36 ++++++++++++++++ > block/blk-settings.c | 24 +++++++++++ > block/blk-sysfs.c | 64 ++++++++++++++++++++++++++++ > include/linux/blkdev.h | 12 ++++++ > include/uapi/linux/fs.h | 3 ++ > 5 files changed, 139 insertions(+) > > diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block > index c57e5b7cb532..f5c56ad91ad6 100644 > --- a/Documentation/ABI/stable/sysfs-block > +++ b/Documentation/ABI/stable/sysfs-block > @@ -155,6 +155,42 @@ Description: > last zone of the device which may be smaller. > > > +What: /sys/block/<disk>/queue/copy_offload > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RW] When read, this file shows whether offloading copy to > + device is enabled (1) or disabled (0). Writing '0' to this ...to a device... > + file will disable offloading copies for this device. > + Writing any '1' value will enable this feature. If device If the device does... > + does not support offloading, then writing 1, will result in > + error. > + > + > +What: /sys/block/<disk>/queue/copy_max_bytes > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RW] While 'copy_max_bytes_hw' is the hardware limit for the > + device, 'copy_max_bytes' setting is the software limit. > + Setting this value lower will make Linux issue smaller size > + copies from block layer. This is the maximum number of bytes that the block layer will allow for a copy request. Must be smaller than or equal to the maximum size allowed by the hardware indicated by copy_max_bytes_hw. Write 0 to use the default kernel settings. > + > + > +What: /sys/block/<disk>/queue/copy_max_bytes_hw > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RO] Devices that support offloading copy functionality may have > + internal limits on the number of bytes that can be offloaded > + in a single operation. The `copy_max_bytes_hw` > + parameter is set by the device driver to the maximum number of > + bytes that can be copied in a single operation. Copy > + requests issued to the device must not exceed this limit. > + A value of 0 means that the device does not > + support copy offload. [RO] This is the maximum number of kilobytes supported in a single data copy offload operation. A value of 0 means that the device does not support copy offload. > + > + > What: /sys/block/<disk>/queue/crypto/ > Date: February 2022 > Contact: linux-block@vger.kernel.org > diff --git a/block/blk-settings.c b/block/blk-settings.c > index 896b4654ab00..350f3584f691 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -59,6 +59,8 @@ void blk_set_default_limits(struct queue_limits *lim) > lim->zoned = BLK_ZONED_NONE; > lim->zone_write_granularity = 0; > lim->dma_alignment = 511; > + lim->max_copy_sectors_hw = 0; > + lim->max_copy_sectors = 0; > } > > /** > @@ -82,6 +84,8 @@ void blk_set_stacking_limits(struct queue_limits *lim) > lim->max_dev_sectors = UINT_MAX; > lim->max_write_zeroes_sectors = UINT_MAX; > lim->max_zone_append_sectors = UINT_MAX; > + lim->max_copy_sectors_hw = ULONG_MAX; > + lim->max_copy_sectors = ULONG_MAX; > } > EXPORT_SYMBOL(blk_set_stacking_limits); > > @@ -183,6 +187,22 @@ void blk_queue_max_discard_sectors(struct request_queue *q, > } > EXPORT_SYMBOL(blk_queue_max_discard_sectors); > > +/** > + * blk_queue_max_copy_sectors_hw - set max sectors for a single copy payload > + * @q: the request queue for the device > + * @max_copy_sectors: maximum number of sectors to copy > + **/ > +void blk_queue_max_copy_sectors_hw(struct request_queue *q, > + unsigned int max_copy_sectors) > +{ > + if (max_copy_sectors >= MAX_COPY_TOTAL_LENGTH) Confusing name as LENGTH may be interpreted as bytes. MAX_COPY_SECTORS would be better. > + max_copy_sectors = MAX_COPY_TOTAL_LENGTH; > + > + q->limits.max_copy_sectors_hw = max_copy_sectors; > + q->limits.max_copy_sectors = max_copy_sectors; > +} > +EXPORT_SYMBOL_GPL(blk_queue_max_copy_sectors_hw); -- Damien Le Moal Western Digital Research
WARNING: multiple messages have this Message-ID (diff)
From: Damien Le Moal <damien.lemoal@opensource.wdc.com> To: Anuj Gupta <anuj20.g@samsung.com>, Jens Axboe <axboe@kernel.dk>, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com, Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>, James Smart <james.smart@broadcom.com>, Chaitanya Kulkarni <kch@nvidia.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org> Cc: bvanassche@acm.org, joshi.k@samsung.com, gost.dev@samsung.com, nitheshshetty@gmail.com, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, ming.lei@redhat.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Nitesh Shetty <nj.shetty@samsung.com> Subject: Re: [dm-devel] [PATCH v8 1/9] block: Introduce queue limits for copy-offload support Date: Wed, 29 Mar 2023 17:40:09 +0900 [thread overview] Message-ID: <e725768d-19f5-a78a-2b05-c0b189624fea@opensource.wdc.com> (raw) In-Reply-To: <20230327084103.21601-2-anuj20.g@samsung.com> On 3/27/23 17:40, Anuj Gupta wrote: > From: Nitesh Shetty <nj.shetty@samsung.com> > > Add device limits as sysfs entries, > - copy_offload (RW) > - copy_max_bytes (RW) > - copy_max_bytes_hw (RO) > > Above limits help to split the copy payload in block layer. > copy_offload: used for setting copy offload(1) or emulation(0). > copy_max_bytes: maximum total length of copy in single payload. > copy_max_bytes_hw: Reflects the device supported maximum limit. > > Reviewed-by: Hannes Reinecke <hare@suse.de> > Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> > Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> > Signed-off-by: Anuj Gupta <anuj20.g@samsung.com> > --- > Documentation/ABI/stable/sysfs-block | 36 ++++++++++++++++ > block/blk-settings.c | 24 +++++++++++ > block/blk-sysfs.c | 64 ++++++++++++++++++++++++++++ > include/linux/blkdev.h | 12 ++++++ > include/uapi/linux/fs.h | 3 ++ > 5 files changed, 139 insertions(+) > > diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block > index c57e5b7cb532..f5c56ad91ad6 100644 > --- a/Documentation/ABI/stable/sysfs-block > +++ b/Documentation/ABI/stable/sysfs-block > @@ -155,6 +155,42 @@ Description: > last zone of the device which may be smaller. > > > +What: /sys/block/<disk>/queue/copy_offload > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RW] When read, this file shows whether offloading copy to > + device is enabled (1) or disabled (0). Writing '0' to this ...to a device... > + file will disable offloading copies for this device. > + Writing any '1' value will enable this feature. If device If the device does... > + does not support offloading, then writing 1, will result in > + error. > + > + > +What: /sys/block/<disk>/queue/copy_max_bytes > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RW] While 'copy_max_bytes_hw' is the hardware limit for the > + device, 'copy_max_bytes' setting is the software limit. > + Setting this value lower will make Linux issue smaller size > + copies from block layer. This is the maximum number of bytes that the block layer will allow for a copy request. Must be smaller than or equal to the maximum size allowed by the hardware indicated by copy_max_bytes_hw. Write 0 to use the default kernel settings. > + > + > +What: /sys/block/<disk>/queue/copy_max_bytes_hw > +Date: November 2022 > +Contact: linux-block@vger.kernel.org > +Description: > + [RO] Devices that support offloading copy functionality may have > + internal limits on the number of bytes that can be offloaded > + in a single operation. The `copy_max_bytes_hw` > + parameter is set by the device driver to the maximum number of > + bytes that can be copied in a single operation. Copy > + requests issued to the device must not exceed this limit. > + A value of 0 means that the device does not > + support copy offload. [RO] This is the maximum number of kilobytes supported in a single data copy offload operation. A value of 0 means that the device does not support copy offload. > + > + > What: /sys/block/<disk>/queue/crypto/ > Date: February 2022 > Contact: linux-block@vger.kernel.org > diff --git a/block/blk-settings.c b/block/blk-settings.c > index 896b4654ab00..350f3584f691 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -59,6 +59,8 @@ void blk_set_default_limits(struct queue_limits *lim) > lim->zoned = BLK_ZONED_NONE; > lim->zone_write_granularity = 0; > lim->dma_alignment = 511; > + lim->max_copy_sectors_hw = 0; > + lim->max_copy_sectors = 0; > } > > /** > @@ -82,6 +84,8 @@ void blk_set_stacking_limits(struct queue_limits *lim) > lim->max_dev_sectors = UINT_MAX; > lim->max_write_zeroes_sectors = UINT_MAX; > lim->max_zone_append_sectors = UINT_MAX; > + lim->max_copy_sectors_hw = ULONG_MAX; > + lim->max_copy_sectors = ULONG_MAX; > } > EXPORT_SYMBOL(blk_set_stacking_limits); > > @@ -183,6 +187,22 @@ void blk_queue_max_discard_sectors(struct request_queue *q, > } > EXPORT_SYMBOL(blk_queue_max_discard_sectors); > > +/** > + * blk_queue_max_copy_sectors_hw - set max sectors for a single copy payload > + * @q: the request queue for the device > + * @max_copy_sectors: maximum number of sectors to copy > + **/ > +void blk_queue_max_copy_sectors_hw(struct request_queue *q, > + unsigned int max_copy_sectors) > +{ > + if (max_copy_sectors >= MAX_COPY_TOTAL_LENGTH) Confusing name as LENGTH may be interpreted as bytes. MAX_COPY_SECTORS would be better. > + max_copy_sectors = MAX_COPY_TOTAL_LENGTH; > + > + q->limits.max_copy_sectors_hw = max_copy_sectors; > + q->limits.max_copy_sectors = max_copy_sectors; > +} > +EXPORT_SYMBOL_GPL(blk_queue_max_copy_sectors_hw); -- Damien Le Moal Western Digital Research -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2023-03-29 8:40 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20230327084154epcas5p2a1d8ee728610929fbba8c7757ad3193e@epcas5p2.samsung.com> 2023-03-27 8:40 ` [PATCH v8 0/9] Implement copy offload support Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta [not found] ` <CGME20230327084216epcas5p3945507ecd94688c40c29195127ddc54d@epcas5p3.samsung.com> 2023-03-27 8:40 ` [PATCH v8 1/9] block: Introduce queue limits for copy-offload support Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 8:40 ` Damien Le Moal [this message] 2023-03-29 8:40 ` Damien Le Moal 2023-03-29 10:41 ` Nitesh Shetty 2023-03-29 10:41 ` [dm-devel] " Nitesh Shetty 2023-03-29 12:24 ` Damien Le Moal 2023-03-29 12:24 ` [dm-devel] " Damien Le Moal 2023-03-29 12:34 ` Nitesh Shetty 2023-03-29 12:34 ` [dm-devel] " Nitesh Shetty [not found] ` <CGME20230327084226epcas5p28e667b25cbb5e4b0e884aa2ca89cbfff@epcas5p2.samsung.com> 2023-03-27 8:40 ` [PATCH v8 2/9] block: Add copy offload support infrastructure Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 8:56 ` Damien Le Moal 2023-03-29 8:56 ` Damien Le Moal [not found] ` <CGME20230327084235epcas5p495559f907ce39184da72a412c5691e43@epcas5p4.samsung.com> 2023-03-27 8:40 ` [PATCH v8 3/9] block: add emulation for copy Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta [not found] ` <CGME20230327084244epcas5p1b0ede867e558ff6faf258de3656a8aa4@epcas5p1.samsung.com> 2023-03-27 8:40 ` [PATCH v8 4/9] fs, block: copy_file_range for def_blk_ops for direct block device Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 12:14 ` Christian Brauner 2023-03-29 12:14 ` [dm-devel] " Christian Brauner 2023-03-29 12:42 ` Nitesh Shetty 2023-03-29 12:42 ` [dm-devel] " Nitesh Shetty 2023-03-30 5:48 ` Christian Brauner 2023-03-30 5:48 ` [dm-devel] " Christian Brauner 2023-03-30 15:21 ` Nitesh Shetty 2023-03-30 15:21 ` [dm-devel] " Nitesh Shetty 2023-03-29 14:07 ` kernel test robot 2023-03-29 14:07 ` [dm-devel] " kernel test robot 2023-03-29 15:30 ` kernel test robot 2023-03-29 15:30 ` [dm-devel] " kernel test robot [not found] ` <CGME20230327084254epcas5p4c5f324c1501062f743895273c302c0a4@epcas5p4.samsung.com> 2023-03-27 8:40 ` [PATCH v8 5/9] nvme: add copy offload support Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta [not found] ` <CGME20230327084303epcas5p22fdd3af683d3eb1b3f503bcf045f578a@epcas5p2.samsung.com> 2023-03-27 8:40 ` [PATCH v8 6/9] nvmet: add copy command support for bdev and file ns Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 13:56 ` kernel test robot 2023-03-29 13:56 ` [dm-devel] " kernel test robot 2023-03-29 18:36 ` kernel test robot 2023-03-29 18:36 ` [dm-devel] " kernel test robot [not found] ` <CGME20230327084312epcas5p377810b172aa6048519591518f8c308d0@epcas5p3.samsung.com> 2023-03-27 8:40 ` [PATCH v8 7/9] dm: Add support for copy offload Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 8:59 ` Damien Le Moal 2023-03-29 8:59 ` [dm-devel] " Damien Le Moal 2023-03-29 12:12 ` Nitesh Shetty 2023-03-29 12:12 ` [dm-devel] " Nitesh Shetty [not found] ` <CGME20230327084322epcas5p12f01e676e47d3c8ba880f3f5d58999b4@epcas5p1.samsung.com> 2023-03-27 8:40 ` [PATCH v8 8/9] dm: Enable copy offload for dm-linear target Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta [not found] ` <CGME20230327084331epcas5p2510ed79d04fe3432c2ec84ce528745c6@epcas5p2.samsung.com> 2023-03-27 8:40 ` [PATCH v8 9/9] null_blk: add support for copy offload Anuj Gupta 2023-03-27 8:40 ` [dm-devel] " Anuj Gupta 2023-03-29 9:04 ` Damien Le Moal 2023-03-29 9:04 ` [dm-devel] " Damien Le Moal 2023-03-29 12:22 ` Nitesh Shetty 2023-03-29 12:22 ` [dm-devel] " Nitesh Shetty
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=e725768d-19f5-a78a-2b05-c0b189624fea@opensource.wdc.com \ --to=damien.lemoal@opensource.wdc.com \ --cc=agk@redhat.com \ --cc=anuj20.g@samsung.com \ --cc=axboe@kernel.dk \ --cc=brauner@kernel.org \ --cc=bvanassche@acm.org \ --cc=dm-devel@redhat.com \ --cc=gost.dev@samsung.com \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=james.smart@broadcom.com \ --cc=joshi.k@samsung.com \ --cc=kbusch@kernel.org \ --cc=kch@nvidia.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=ming.lei@redhat.com \ --cc=nitheshshetty@gmail.com \ --cc=nj.shetty@samsung.com \ --cc=sagi@grimberg.me \ --cc=snitzer@kernel.org \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.