From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2369BC433E0 for ; Fri, 7 Aug 2020 12:17:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01178221E2 for ; Fri, 7 Aug 2020 12:17:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="Q0+V5XR/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728374AbgHGMRc (ORCPT ); Fri, 7 Aug 2020 08:17:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728103AbgHGMR3 (ORCPT ); Fri, 7 Aug 2020 08:17:29 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B806C061575 for ; Fri, 7 Aug 2020 05:17:28 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id e11so1421986otk.4 for ; Fri, 07 Aug 2020 05:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=cHhul6rH38ZNzpMfO6dKhe4PMghBWM5YOHqxidZYrEI=; b=Q0+V5XR/4DZ+5wlClLZ1wdvPnQGymcq+AEA9vNk3GT5nYPpmv58DEspYrmc6FiNwG6 HZVm83pLAZ3ZeiIlLgK/IbQVMZVzv6qu7AB6UiNsTeZxWu5Y86nRuGaJngnk3deuh/ig xn/iaNrNlRCP7MleonoQ8dLd7PgzAYnu8lU0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=cHhul6rH38ZNzpMfO6dKhe4PMghBWM5YOHqxidZYrEI=; b=WqUxNcl4PCxXbaLGmI3A+NQGq93ctk9Y0+AL76nHs//1KZfMxk+HkMfJ0/2mbqAeBz 4c2PxwOinU9acBQeNeaAIrCFXZDFO6yIrOOMpWqZ0zSwxCNgkfRXgCGnDAXRe6JE+UVh KziR/fWbxZuEaMaBn9MeW2DbaFTwSvGBJ+j+ea0XUEzfyTEGKKyGOXPWbtv47tbJe/e3 sguse7SYFwdbnwEsN1PYQXEq/DzLJ2hIh8mLkejQvA91Lajceb9uuDVeRfaIvYnt+OkP w+Pzxc5h4qkV9hNiJ2HXBDr6xWj8AZQKGWsPvDz5hF8NeaHDuukgyeW382RCFPo5tMXd TWEQ== X-Gm-Message-State: AOAM530yiY0wHzVLhBdLbiKKnBiVycRu+ERixbOi8dbH4SsbGLmvM1OQ axfFV7oyhGvLCRztHKJfRAtIu7kfyBa410t1yko6UA== X-Google-Smtp-Source: ABdhPJxSlo8R1h3b5kUUtUzcc4ngskWxE3KSllyHuXeEWvaU3H5D0l9U3v2y/vrWniDe4xXaPB/HCahji9/47i9sJaI= X-Received: by 2002:a9d:7449:: with SMTP id p9mr11094677otk.360.1596802647241; Fri, 07 Aug 2020 05:17:27 -0700 (PDT) From: Muneendra Kumar M References: <1596507196-27417-1-git-send-email-muneendra.kumar@broadcom.com> <1596507196-27417-17-git-send-email-muneendra.kumar@broadcom.com> <61d2fd75-84ea-798b-aee9-b07957ac8f1b@suse.de> <08b9825b-6abb-c077-ac0d-bd63f10f2ac2@broadcom.com> <227c5ba1-8a9c-3ec9-5a0f-662a4736c66f@redhat.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 thread-index: AQIDyhmBPqdmqCKUdNTZliBUbPkt/AI5BKetAom9APICL6c0jAMHD3TmAjtZC5MBe/Ed2QIv9leoAyMPjxIBrC+2XKgsTm3g Date: Fri, 7 Aug 2020 17:47:24 +0530 Message-ID: <7e76e1464e794a79861ea9846e0a5370@mail.gmail.com> Subject: RE: [RFC 16/16] lpfc: vmid: Introducing vmid in io path. To: Paolo Bonzini , James Smart , Hannes Reinecke , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org Cc: emilne@redhat.com, mkumar@redhat.com, Gaurav Srivastava , James Smart , Ming Lei , Tejun Heo Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org > > Before the daemon issues the UUID and pid to the fabric interface, it > needs to check whether the VM is in running state or not. > > If it the VM is in running state then only it issues the VM details. > > And if the cgroup's are not setup as you mentioned the interface will > return a failure(with a proper logs) and the daemon will retry after > some time. > > And this also helps us to keep track of PID to UUID mapping at daemon > level. >Why would that be useful? Again, the mapping of the UUID is _not_ to a >PID, it is to a cgroup. There is no concept of a VM PID; you could >legitimately have I/O in a separate process than say the QEMU process, and >that I/O >process could legitimately reside in a separate blkcg than QEMU. Agreed . When I run ps -aef | grep we got a pid. ps -aef | grep mmkvm1 root 3627 1 0 04:20 ? 00:00:34 /usr/libexec/qemu-kvm -name testmmkvm1 -S And I was talking about at the below one PIDS(3627) .And with the help of these PIDS I was able to reach blkcg. Correct me if iam going in a wrong direction. And even when I run the below command it pointed me to the same pid. cat /sys/fs/cgroup/blkio/machine.slice/machine-qemu\\x2d7\\x2dtestmmkvm1.scope/tasks 3627 -->/usr/libexec/qemu-kvm -name testmmkvm1 3655 --> [kvm-nx-lpage-re] 3658--> vhost-3627 And I was talking about the above PIDS(3627) to be passed to the interface along with UUID. >There is no need for any daemon, and I'm not even sure which daemon would >be handling this. App identifier should be purely a kernel concept with no >userspace state. Agreed App identifier is a pure kernel concept. And the user can only provide the info what needs to be filled in it using an interface. Iam talking about FC transport daemon. One of the feature of this daemon is to track all the running VM's and push the appid information to the blk cgroup via the interface provided by the fabric And this feature is under development. Paolo