All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muneendra Kumar M <muneendra.kumar@broadcom.com>
To: Tejun Heo <tj@kernel.org>, Hannes Reinecke <hare@suse.de>
Cc: Ming Lei <tom.leiming@gmail.com>,
	James Smart <james.smart@broadcom.com>,
	Daniel Wagner <dwagner@suse.de>,
	linux-block <linux-block@vger.kernel.org>,
	Linux SCSI List <linux-scsi@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ewan Milne <emilne@redhat.com>,
	mkumar@redhat.com
Subject: RE: [RFC 01/16] blkcg:Introduce blkio.app_identifier knob to blkio controller
Date: Wed, 5 Aug 2020 22:44:56 +0530	[thread overview]
Message-ID: <c40bc34840566366177a84b0d8b7ae90@mail.gmail.com> (raw)
In-Reply-To: <20200805143913.GC4819@mtj.thefacebook.com>

Hi Tejun,
Our main requirement is to track the bio requests coming from different VM
/container applications  at the blk device layer(fc,scsi,nvme).
By the time IO request comes to the blk device layer, the context of the
application is lost and we can't track whose IO this belongs.

In our approach we used the block cgroup to achieve this requirement.
Since Requests also have access to the block cgroup via
bio->bi_blkg->blkcg, and from there we can get the VM UUID.
Therefore we added the VM UUID(app_identifier) to struct blkcg and define
the accessors in blkcg_files and blkcg_legacy_files.

Could you please let me know is there any another way where we can get the
VM UUID info with the help of blkcg.

Regards,
Muneendra.






-----Original Message-----
From: Tejun Heo [mailto:htejun@gmail.com] On Behalf Of Tejun Heo
Sent: Wednesday, August 5, 2020 8:09 PM
To: Hannes Reinecke <hare@suse.de>
Cc: Ming Lei <tom.leiming@gmail.com>; James Smart
<james.smart@broadcom.com>; Daniel Wagner <dwagner@suse.de>; Muneendra
<muneendra.kumar@broadcom.com>; linux-block <linux-block@vger.kernel.org>;
Linux SCSI List <linux-scsi@vger.kernel.org>; Paolo Bonzini
<pbonzini@redhat.com>; Ewan Milne <emilne@redhat.com>; mkumar@redhat.com
Subject: Re: [RFC 01/16] blkcg:Introduce blkio.app_identifier knob to
blkio controller

Hello,

On Wed, Aug 05, 2020 at 08:33:19AM +0200, Hannes Reinecke wrote:
> None of these are guaranteed to be either present or unique.
> It's not uncommon to have VMs with more than one MAC address, and any
> other unique identifier like system UUID is not required to be present.

I have a really hard time seeing how this fits into block cgroup
interface.
The last time we did something similar (tagging from cgroup interface
side) was for netcls and it ended poorly. There are basic problems with
e.g.
delegation as these things are at odds with everything else sharing the
interface.

My not-too-well informed suggestions are either building mapping somewhere
in the stack or at least implement the interface where it fits better so
that people who don't need app_identifier don't see them and preferably
can disable them. I don't mind cgroup data structs carrying extra bits for
stuff which want to make use of the cgroup tree but I'm a pretty firm nack
on the proposed interface.

Thanks.

--
tejun

  reply	other threads:[~2020-08-05 19:25 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04  2:13 [RFC 00/16] Application specific identification support Muneendra
2020-08-04  2:13 ` [RFC 01/16] blkcg:Introduce blkio.app_identifier knob to blkio controller Muneendra
2020-08-04 11:31   ` Daniel Wagner
2020-08-04 14:21     ` Tejun Heo
2020-08-05  0:39       ` James Smart
2020-08-05  3:59         ` Ming Lei
2020-08-05  6:33           ` Hannes Reinecke
2020-08-05 14:39             ` Tejun Heo
2020-08-05 17:14               ` Muneendra Kumar M [this message]
2020-08-05 17:31                 ` Tejun Heo
2020-08-06  2:22                 ` Ming Lei
2020-08-06 12:31                   ` Muneendra Kumar M
2020-08-06 13:41                   ` Paolo Bonzini
2020-08-04  2:13 ` [RFC 02/16] lpfc: vmid: Add the datastructure for supporting VMID in lpfc Muneendra
2020-08-04  2:13 ` [RFC 03/16] lpfc: vmid: API to check if VMID is enabled Muneendra
2020-08-04  2:13 ` [RFC 04/16] lpfc: vmid: Supplementary data structures for vmid Muneendra
2020-08-04  2:13 ` [RFC 05/16] lpfc: vmid: Forward declarations for APIs Muneendra
2020-08-04  2:13 ` [RFC 06/16] lpfc: vmid: Add support for vmid in mailbox command Muneendra
2020-08-04  2:13 ` [RFC 07/16] lpfc: vmid: VMID params initialization Muneendra
2020-08-04  2:13 ` [RFC 08/16] lpfc: vmid: vmid resource allocation Muneendra
2020-08-04  2:13 ` [RFC 09/16] lpfc: vmid: cleanup vmid resources Muneendra
2020-08-04  2:13 ` [RFC 10/16] lpfc: vmid: Implements ELS commands for appid patch Muneendra
2020-08-04  2:13 ` [RFC 11/16] lpfc: vmid: Functions to manage vmids Muneendra
2020-08-04  2:13 ` [RFC 12/16] lpfc: vmid: Implements CT commands for appid Muneendra
2020-08-04  2:13 ` [RFC 13/16] lpfc: vmid: Appends the vmid in the wqe before sending request Muneendra
2020-08-04  2:13 ` [RFC 14/16] lpfc: vmid: Timeout implementation for vmid Muneendra
2020-08-04  2:13 ` [RFC 15/16] lpfc: vmid: Adding qfpa and vmid timeout check in worker thread Muneendra
2020-08-04  2:13 ` [RFC 16/16] lpfc: vmid: Introducing vmid in io path Muneendra
2020-08-05  7:16   ` Hannes Reinecke
2020-08-05 23:38     ` James Smart
2020-08-06 12:34       ` Muneendra Kumar M
2020-08-06 14:32         ` Paolo Bonzini
2020-08-06 16:26           ` Muneendra Kumar M
2020-08-06 18:41             ` Paolo Bonzini
2020-08-07 11:24               ` Muneendra Kumar M
2020-08-07 11:38                 ` Paolo Bonzini
2020-08-07 12:17                   ` Muneendra Kumar M
2020-08-10  9:03                     ` Paolo Bonzini
2020-08-10 12:13                       ` Muneendra Kumar M
2020-08-12  7:54                         ` Paolo Bonzini
2020-08-12 12:16                           ` Muneendra Kumar M
2020-08-07 12:32                   ` Muneendra Kumar M
2020-08-11 23:48             ` James Smart
2020-08-06 14:41         ` Tejun Heo
2020-08-06 14:46           ` Paolo Bonzini
2020-08-06 14:48             ` Tejun Heo
2020-08-06 14:54               ` Paolo Bonzini
2020-08-06 14:59                 ` Tejun Heo
2020-08-06 18:39                   ` Paolo Bonzini
2020-08-06 18:49                     ` Tejun Heo
2020-08-06 19:20                       ` Paolo Bonzini
2020-08-06 19:32                         ` Tejun Heo
2020-08-07 12:14                           ` Paolo Bonzini

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=c40bc34840566366177a84b0d8b7ae90@mail.gmail.com \
    --to=muneendra.kumar@broadcom.com \
    --cc=dwagner@suse.de \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=james.smart@broadcom.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkumar@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tj@kernel.org \
    --cc=tom.leiming@gmail.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 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.