From: Bart Van Assche <bvanassche@acm.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [dm-devel] [RFC PATCH 1/3] block: add copy offload support
Date: Thu, 3 Feb 2022 14:49:57 -0800 [thread overview]
Message-ID: <a2ec9086-72d2-4a4e-c4fa-fe53bf5ba092@acm.org> (raw)
In-Reply-To: <alpine.LRH.2.02.2202031310530.28604@file01.intranet.prod.int.rdu2.redhat.com>
On 2/3/22 10:50, Mikulas Patocka wrote:
> On Tue, 1 Feb 2022, Bart Van Assche wrote:
>> On 2/1/22 10:32, Mikulas Patocka wrote:
>>> /**
>>> + * blk_queue_max_copy_sectors - set maximum copy offload sectors for the
>>> queue
>>> + * @q: the request queue for the device
>>> + * @size: the maximum copy offload sectors
>>> + */
>>> +void blk_queue_max_copy_sectors(struct request_queue *q, unsigned int size)
>>> +{
>>> + q->limits.max_copy_sectors = size;
>>> +}
>>> +EXPORT_SYMBOL_GPL(blk_queue_max_copy_sectors);
>>
>> Please either change the unit of 'size' into bytes or change its type into
>> sector_t.
>
> blk_queue_chunk_sectors, blk_queue_max_discard_sectors,
> blk_queue_max_write_same_sectors, blk_queue_max_write_zeroes_sectors,
> blk_queue_max_zone_append_sectors also have the unit of sectors and the
> argument is "unsigned int". Should blk_queue_max_copy_sectors be
> different?
As far as I know using the type sector_t for variables that represent a
number of sectors is a widely followed convention:
$ git grep -w sector_t | wc -l
2575
I would appreciate it if that convention would be used consistently,
even if that means modifying existing code.
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-02-03 22:50 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220127071544uscas1p2f70f4d2509f3ebd574b7ed746d3fa551@uscas1p2.samsung.com>
[not found] ` <f0e19ae4-b37a-e9a3-2be7-a5afb334a5c3@nvidia.com>
2022-01-28 19:59 ` [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload Adam Manzanares
2022-01-31 11:49 ` Johannes Thumshirn
2022-01-31 19:03 ` Bart Van Assche
2022-02-01 1:54 ` Luis Chamberlain
[not found] ` <20220201102122.4okwj2gipjbvuyux@mpHalley-2>
2022-02-01 18:31 ` [dm-devel] [RFC PATCH 0/3] NVMe copy offload patches Mikulas Patocka
2022-02-01 18:32 ` [dm-devel] [RFC PATCH 1/3] block: add copy offload support Mikulas Patocka
2022-02-01 19:18 ` Bart Van Assche
2022-02-03 18:50 ` Mikulas Patocka
2022-02-03 20:11 ` Keith Busch
2022-02-03 22:49 ` Bart Van Assche [this message]
2022-02-04 12:09 ` Mikulas Patocka
2022-02-04 13:34 ` Jens Axboe
2022-02-02 16:21 ` Keith Busch
2022-02-02 16:40 ` Mikulas Patocka
2022-02-02 18:40 ` Knight, Frederick
2022-02-01 18:33 ` [dm-devel] [RFC PATCH 2/3] nvme: " Mikulas Patocka
2022-02-01 19:18 ` Bart Van Assche
2022-02-01 19:25 ` Mikulas Patocka
2022-02-01 18:33 ` [dm-devel] [RFC PATCH 3/3] nvme: add the "debug" host driver Mikulas Patocka
2022-02-02 6:01 ` Adam Manzanares
2022-02-03 16:06 ` Luis Chamberlain
2022-02-03 16:15 ` Christoph Hellwig
2022-02-03 19:34 ` Luis Chamberlain
2022-02-03 19:46 ` Adam Manzanares
2022-02-03 20:57 ` Mikulas Patocka
2022-02-03 22:52 ` Adam Manzanares
2022-02-04 3:00 ` Chaitanya Kulkarni
2022-02-04 3:05 ` Chaitanya Kulkarni
2022-02-02 8:00 ` Chaitanya Kulkarni
2022-02-02 12:38 ` Klaus Jensen
2022-02-03 15:38 ` Luis Chamberlain
2022-02-03 16:52 ` Keith Busch
2022-02-03 19:50 ` Adam Manzanares
2022-02-04 3:12 ` Chaitanya Kulkarni
2022-02-04 6:28 ` Damien Le Moal
2022-02-04 7:58 ` Chaitanya Kulkarni
2022-02-04 8:24 ` Javier González
2022-02-04 9:58 ` Chaitanya Kulkarni
2022-02-04 11:34 ` Javier González
2022-02-04 14:15 ` Hannes Reinecke
2022-02-04 14:24 ` Keith Busch
2022-02-04 16:01 ` Christoph Hellwig
2022-02-04 19:41 ` [dm-devel] [RFC PATCH 0/3] NVMe copy offload patches Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 00/10] Add Copy offload support Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 01/10] block: make bio_map_kern() non static Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 02/10] block: Introduce queue limits for copy-offload support Nitesh Shetty
2022-02-08 7:01 ` Damien Le Moal
2022-02-08 18:43 ` Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 03/10] block: Add copy offload support infrastructure Nitesh Shetty
2022-02-07 22:45 ` kernel test robot
2022-02-07 23:26 ` kernel test robot
2022-02-08 7:21 ` Damien Le Moal
2022-02-09 10:22 ` Nitesh Shetty
2022-02-09 7:48 ` Dan Carpenter
2022-02-09 10:32 ` Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 04/10] block: Introduce a new ioctl for copy Nitesh Shetty
2022-02-09 3:39 ` kernel test robot
2022-02-07 14:13 ` [dm-devel] [PATCH v2 05/10] block: add emulation " Nitesh Shetty
2022-02-08 3:20 ` kernel test robot
2022-02-16 13:32 ` Mikulas Patocka
2022-02-17 13:18 ` Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 06/10] nvme: add copy support Nitesh Shetty
2022-02-10 7:08 ` kernel test robot
2022-02-07 14:13 ` [dm-devel] [PATCH v2 07/10] nvmet: add copy command support for bdev and file ns Nitesh Shetty
2022-02-07 18:10 ` kernel test robot
2022-02-07 20:12 ` kernel test robot
2022-02-10 8:31 ` kernel test robot
2022-02-11 7:52 ` Dan Carpenter
2022-02-07 14:13 ` [dm-devel] [PATCH v2 08/10] dm: Add support for copy offload Nitesh Shetty
2022-02-16 13:51 ` Mikulas Patocka
2022-02-24 12:42 ` Nitesh Shetty
2022-02-25 9:12 ` Mikulas Patocka
2022-02-07 14:13 ` [dm-devel] [PATCH v2 09/10] dm: Enable copy offload for dm-linear target Nitesh Shetty
2022-02-07 14:13 ` [dm-devel] [PATCH v2 10/10] dm kcopyd: use copy offload support Nitesh Shetty
2022-02-07 9:57 ` [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload Nitesh Shetty
2022-02-02 5:57 ` Kanchan Joshi
2022-02-07 10:45 ` David Disseldorp
2022-03-01 17:34 ` Nikos Tsironis
[not found] ` <c4124f39-1ee9-8f34-e731-42315fee15f9@nvidia.com>
2022-03-03 18:36 ` Nikos Tsironis
2022-03-08 20:48 ` Nikos Tsironis
2022-03-09 8:51 ` Mikulas Patocka
2022-03-09 15:49 ` Nikos Tsironis
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=a2ec9086-72d2-4a4e-c4fa-fe53bf5ba092@acm.org \
--to=bvanassche@acm.org \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mpatocka@redhat.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