From: Hannes Reinecke <hare@suse.de>
To: Muneendra <muneendra.kumar@broadcom.com>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
tj@kernel.org, linux-nvme@lists.infradead.org
Cc: pbonzini@redhat.com, jsmart2021@gmail.com, mkumar@redhat.com,
emilne@redhat.com
Subject: Re: [PATCH v4 02/19] blkcg: Added a app identifier support for blkcg
Date: Mon, 16 Nov 2020 08:31:44 +0100 [thread overview]
Message-ID: <1a779905-e1d2-1c3b-1825-7a406e9b5ed6@suse.de> (raw)
In-Reply-To: <1604895845-2587-3-git-send-email-muneendra.kumar@broadcom.com>
On 11/9/20 5:23 AM, Muneendra wrote:
> This Patch added a unique application identifier i.e
> app_id knob to blkcg which allows identification of traffic
> sources at an individual cgroup based Applications
> (ex:virtual machine (VM))level in both host and
> fabric infrastructure.
>
> Provided the interface blkcg_get_fc_appid to
> grab the app identifier associated with a bio.
>
> Provided the interface blkcg_set_fc_appid to
> set the app identifier in a blkcgrp associated with cgroup id
>
> Added a new config BLK_CGROUP_FC_APPID and moved the changes
> under this config
>
> Signed-off-by: Muneendra <muneendra.kumar@broadcom.com>
>
> ---
> v4:
> No change
>
> v3:
> Renamed the functions and app_id to more specific
>
> Addressed the reference leaks in blkcg_set_app_identifier
>
> Added a new config BLK_CGROUP_FC_APPID and moved the changes
> under this config
>
> Added blkcg_get_fc_appid,blkcg_set_fc_appid as inline functions
>
> v2:
> renamed app_identifier to app_id
> removed the sysfs interface blkio.app_identifie under
> ---
> block/Kconfig | 9 ++++++
> include/linux/blk-cgroup.h | 65 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/block/Kconfig b/block/Kconfig
> index bbad5e8bbffe..ed22df654ce5 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -144,6 +144,15 @@ config BLK_CGROUP_IOLATENCY
>
> Note, this is an experimental interface and could be changed someday.
>
> +config BLK_CGROUP_FC_APPID
> + bool "Enable support to track FC io Traffic across cgroup applications"
> + depends on BLK_CGROUP=y
> + help
> + Enabling this option enables the support to track FC io traffic across
> + cgroup applications.It enables the Fabric and the storage targets to
> + identify, monitor, and handle FC traffic based on vm tags by inserting
> + application specific identification into the FC frame.
> +
Please replace 'io' with 'I/O'.
> config BLK_CGROUP_IOCOST
> bool "Enable support for cost model based cgroup IO controller"
> depends on BLK_CGROUP=y
> diff --git a/include/linux/blk-cgroup.h b/include/linux/blk-cgroup.h
> index c8fc9792ac77..00ea1cfa3420 100644
> --- a/include/linux/blk-cgroup.h
> +++ b/include/linux/blk-cgroup.h
> @@ -30,6 +30,8 @@
>
> /* Max limits for throttle policy */
> #define THROTL_IOPS_MAX UINT_MAX
> +#define APPID_LEN 128
> +
>
> #ifdef CONFIG_BLK_CGROUP
>
> @@ -55,6 +57,9 @@ struct blkcg {
> struct blkcg_policy_data *cpd[BLKCG_MAX_POLS];
>
> struct list_head all_blkcgs_node;
> +#ifdef CONFIG_BLK_CGROUP_FC_APPID
> + char fc_app_id[APPID_LEN];
> +#endif
> #ifdef CONFIG_CGROUP_WRITEBACK
> struct list_head cgwb_list;
> #endif
If this is an UUID, wouldn't it be better to use 'uuid_t' here?
> @@ -660,4 +665,64 @@ static inline void blk_cgroup_bio_start(struct bio *bio) { }
>
> #endif /* CONFIG_BLOCK */
> #endif /* CONFIG_BLK_CGROUP */
> +
> +#ifdef CONFIG_BLK_CGROUP_FC_APPID
> +/*
> + * Sets the fc_app_id field associted to blkcg
> + * @buf: application identifier
> + * @id: cgrp id
> + * @len: size of appid
> + */
> +static inline int blkcg_set_fc_appid(char *buf, u64 id, size_t len)
> +{
> + struct cgroup *cgrp = NULL;
> + struct cgroup_subsys_state *css = NULL;
> + struct blkcg *blkcg = NULL;
> + int ret = 0;
> +
> + cgrp = cgroup_get_from_kernfs_id(id);
> + if (!cgrp)
> + return -ENOENT;
> + css = cgroup_get_e_css(cgrp, &io_cgrp_subsys);
> + if (!css) {
> + ret = -ENOENT;
> + goto out_cgrp_put;
> + }
> + blkcg = css_to_blkcg(css);
> + if (!blkcg) {
> + ret = -ENOENT;
> + goto out_put;
> + }
> + if (len > APPID_LEN) {
> + ret = -EINVAL;
> + goto out_put;
> + }
> + strlcpy(blkcg->fc_app_id, buf, len);
String or UUID?
And will it be NULL-terminated?
Wouldn't it be better to use 'memcpy' here?
And it is NULL terminated: what happens if the user sets a 128-byte
string? IE shouldn't the app_id be 129 bytes long if it's assumed to be
NULL-terminated?
> +out_put:
> + css_put(css);
> +out_cgrp_put:
> + cgroup_put(cgrp);
> + return ret;
> +}
> +
> +/**
> + * blkcg_get_fc_appid - grab the app identifier associated with a bio
> + * @bio: target bio
> + *
> + * This returns the app identifier associated with a bio,
> + * %NULL if not associated.
> + * Callers are expected to either handle %NULL or know association has been
> + * done prior to calling this.
> + */
> +static inline char *blkcg_get_fc_appid(struct bio *bio)
> +{
> + if (bio && bio->bi_blkg &&
> + strlen(bio->bi_blkg->blkcg->fc_app_id))
> + return bio->bi_blkg->blkcg->fc_app_id;
> + return NULL;
> +}
Same question as above: Is the string NULL terminated or not?
And if not, how do you specify the length of the 'app_id' variable?
> +#else
> +static inline int blkcg_set_fc_appid(char *buf, u64 id, size_t len) { return -EINVAL; }
> +static inline char *blkcg_get_fc_appid(struct bio *bio) { return NULL; }
> +#endif /*CONFIG_BLK_CGROUP_FC_APPID*/
> #endif /* _BLK_CGROUP_H */
>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-11-16 7:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 4:23 [PATCH v4 00/19] blkcg:Support to track FC storage blk io traffic Muneendra
2020-11-09 4:23 ` [PATCH v4 01/19] cgroup: Added cgroup_get_from_kernfs_id Muneendra
2020-11-16 7:25 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 02/19] blkcg: Added a app identifier support for blkcg Muneendra
2020-11-09 13:55 ` Tejun Heo
2020-11-16 7:31 ` Hannes Reinecke [this message]
2020-11-18 9:39 ` Muneendra Kumar M
2020-11-09 4:23 ` [PATCH v4 03/19] nvme: Added a newsysfs attribute appid_store Muneendra
2020-11-16 7:39 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 04/19] lpfc: vmid: Add the datastructure for supporting VMID in lpfc Muneendra
2020-11-16 7:41 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 05/19] lpfc: vmid: API to check if VMID is enabled Muneendra
2020-11-16 7:44 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 06/19] lpfc: vmid: Supplementary data structures for vmid Muneendra
2020-11-16 7:49 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 07/19] lpfc: vmid: Forward declarations for APIs Muneendra
2020-11-16 7:50 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 08/19] lpfc: vmid: Add support for vmid in mailbox command Muneendra
2020-11-16 7:52 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 09/19] lpfc: vmid: VMID params initialization Muneendra
2020-11-16 7:53 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 10/19] lpfc: vmid: vmid resource allocation Muneendra
2020-11-16 7:56 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 11/19] lpfc: vmid: cleanup vmid resources Muneendra
2020-11-16 7:56 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 12/19] lpfc: vmid: Implements ELS commands for appid patch Muneendra
2020-11-16 8:03 ` Hannes Reinecke
2020-11-09 4:23 ` [PATCH v4 13/19] lpfc: vmid: Functions to manage vmids Muneendra
2020-11-16 8:06 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 14/19] lpfc: vmid: Implements CT commands for appid Muneendra
2020-11-16 8:08 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 15/19] lpfc: vmid: Appends the vmid in the wqe before sending request Muneendra
2020-11-16 8:10 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 16/19] lpfc: vmid: Timeout implementation for vmid Muneendra
2020-11-16 8:11 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 17/19] lpfc: vmid: Adding qfpa and vmid timeout check in worker thread Muneendra
2020-11-16 8:12 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 18/19] lpfc: vmid: Introducing vmid in io path Muneendra
2020-11-16 8:13 ` Hannes Reinecke
2020-11-09 4:24 ` [PATCH v4 19/19] scsi: Made changes in Kconfig to select BLK_CGROUP_FC_APPID Muneendra
2020-11-16 8:15 ` Hannes Reinecke
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=1a779905-e1d2-1c3b-1825-7a406e9b5ed6@suse.de \
--to=hare@suse.de \
--cc=emilne@redhat.com \
--cc=jsmart2021@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mkumar@redhat.com \
--cc=muneendra.kumar@broadcom.com \
--cc=pbonzini@redhat.com \
--cc=tj@kernel.org \
/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