From: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Cc: "hch@lst.de" <hch@lst.de>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"sagi@grimberg.me" <sagi@grimberg.me>
Subject: Re: [PATCH V11 4/4] nvme: add comments to nvme_zns_alloc_report_buffer
Date: Thu, 11 Mar 2021 05:36:53 +0000 [thread overview]
Message-ID: <BYAPR04MB49658642053EC41432FCD9CC86909@BYAPR04MB4965.namprd04.prod.outlook.com> (raw)
In-Reply-To: BL0PR04MB6514516766FD5F343D4415AEE7909@BL0PR04MB6514.namprd04.prod.outlook.com
On 3/10/21 21:08, Damien Le Moal wrote:
> On 2021/03/11 13:39, Chaitanya Kulkarni wrote:
>> The report zone buffer calculation is dependent nvme report zones
>> header, nvme report zone descriptor and on the various block
>> layer request queue attributes such as queue_max_hw_sectors(),
>> queue_max_segments(). These queue_XXX attributes are calculated on
>> different ctrl values in the nvme-core.
>>
>> Add clear comments about what values we are using and how they are
>> calculated based on the controller's attributes.
>>
>> This is needed since when referencing the code after long time it is not
>> straight forward to understand how we calculate the buffer size given
>> that there are variables and ctrl attributes involved.
>>
>> Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
>> ---
>> drivers/nvme/host/zns.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/nvme/host/zns.c b/drivers/nvme/host/zns.c
>> index bc2f344f0ae0..c2d08d9cc269 100644
>> --- a/drivers/nvme/host/zns.c
>> +++ b/drivers/nvme/host/zns.c
>> @@ -125,16 +125,38 @@ static void *nvme_zns_alloc_report_buffer(struct nvme_ns *ns,
>> size_t bufsize;
>> void *buf;
>>
>> + /*
>> + * Set the minimum buffer size for report zone header and one zone
>> + * descriptor.
>> + */
>> const size_t min_bufsize = sizeof(struct nvme_zone_report) +
>> sizeof(struct nvme_zone_descriptor);
> This seems unused. And not really useful anyway since if this function is being
> called, it should be clear already that at least one zone can be reported, that
> is, the report start sector is below capacity.
Okay will remove the comment V12.
>>
>> + /*
>> + * Recalculate the number of zones based on disk size of zone size.
>> + */
>> nr_zones = min_t(unsigned int, nr_zones,
>> get_capacity(ns->disk) >> ilog2(ns->zsze));
>>
>> + /*
>> + * Calculate the buffer size based on the report zone header and number
>> + * of zone descriptors are required for each zone.
>> + */
> This comment is not really useful.
Okay will remove it in V12.
>
>> bufsize = sizeof(struct nvme_zone_report) +
>> nr_zones * sizeof(struct nvme_zone_descriptor);
>> +
>> + /*
>> + * Recalculate and Limit the buffer size to queue max hw sectors. For
>> + * NVMe queue max hw sectors are calcualted based on controller's
>> + * Maximum Data Transfer Size (MDTS).
>> + */
Will remove the above comment.
> What combining this comment and the next into:
>
> /*
> * Limit the buffer size to the maximum data transfer size and on
> * the maximum number of segments allowed.
> */
Will use the above comment.
> Simpler in my opinion.
>> bufsize = min_t(size_t, bufsize,
>> queue_max_hw_sectors(q) << SECTOR_SHIFT);
>> + /*
>> + * Recalculate and Limit the buffer size to queue max segments. For
>> + * NVMe queue max segments are calculated based on how many controller
>> + * pages are needed to fit the max hw sectors.
>> + */
Will remove above comment.
>> bufsize = min_t(size_t, bufsize, queue_max_segments(q) << PAGE_SHIFT);
>>
>> while (bufsize >= min_bufsize) {
>>
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-03-11 5:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 4:39 [PATCH V11 0/4] nvmet: add ZBD backend support Chaitanya Kulkarni
2021-03-11 4:39 ` [PATCH V11 1/4] nvmet: add NVM Command Set Identifier support Chaitanya Kulkarni
2021-03-11 4:39 ` [PATCH V11 2/4] nvmet: add ZBD over ZNS backend support Chaitanya Kulkarni
2021-03-11 5:14 ` Damien Le Moal
2021-03-11 5:29 ` Chaitanya Kulkarni
2021-03-11 5:39 ` Damien Le Moal
2021-03-11 5:41 ` Chaitanya Kulkarni
2021-03-11 4:39 ` [PATCH V11 3/4] nvmet: add nvmet_req_bio put helper for backends Chaitanya Kulkarni
2021-03-11 4:39 ` [PATCH V11 4/4] nvme: add comments to nvme_zns_alloc_report_buffer Chaitanya Kulkarni
2021-03-11 5:08 ` Damien Le Moal
2021-03-11 5:36 ` Chaitanya Kulkarni [this message]
2021-03-11 6:22 ` hch
2021-03-11 6:22 ` Chaitanya Kulkarni
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=BYAPR04MB49658642053EC41432FCD9CC86909@BYAPR04MB4965.namprd04.prod.outlook.com \
--to=chaitanya.kulkarni@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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).