From: Neo Jia <cjia@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Ruan, Shuai" <shuai.ruan@intel.com>,
"Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
qemu-devel <qemu-devel@nongnu.org>,
Alex Williamson <alex.williamson@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
"Paul Durrant (Paul.Durrant@citrix.com)"
<Paul.Durrant@citrix.com>,
"Malcolm Crossley (malcolm.crossley@citrix.com)"
<malcolm.crossley@citrix.com>
Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.
Date: Wed, 17 Feb 2016 02:34:09 -0800 [thread overview]
Message-ID: <20160217103409.GB11166@nvidia.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F7B674F@SHSMSX101.ccr.corp.intel.com>
On Wed, Feb 17, 2016 at 09:52:04AM +0000, Tian, Kevin wrote:
> > From: Neo Jia [mailto:cjia@nvidia.com]
> > Sent: Wednesday, February 17, 2016 5:35 PM
> >
> > On Wed, Feb 17, 2016 at 08:57:08AM +0000, Tian, Kevin wrote:
> > > > From: Neo Jia [mailto:cjia@nvidia.com]
> > > > Sent: Wednesday, February 17, 2016 3:55 PM
> > >
> > If we can make it free, why not?
>
> I can buy-in this argument.
Great!
>
> Qemu is not a kernel component. And UUID is OPTIONAL for Qemu.
>
> KVM is the kernel component. It doesn't use UUID at all. the relation between
> UUID and VM is fully maintained in user space.
Hold on ... we are talking about the vgpu.ko not KVM right?
UUID is just a generic way to represent an object, here we use a uuid to
represent a virtual gpu device.
>
> >
> > Please also note that using UUID to represent a virtual gpu device directory
> > doesn't mean UUID is part of a GPU resource.
>
> but it adds a hard dependency on another resource - UUID.
>
> >
> > >
> > > So let's keep UUID as an optional parameter. When UUID is provided, it
> > > will be included in the vGPU name then your requirement can be met.
> > >
> >
> > Like I have said before, we are seeking a generic interface to allow upper layer
> > software stack to manage vgpu device for different vendors, so we should not really
> > consider "an optional path for vgpu device discovery" at all.
> >
> > This is why I think we should use this UUID as a generic management interface,
> > and we shouldn't have anything optional.
> >
>
> I don't buy-in this argument. I always think kernel design should provide
> enough flexibility, instead of assuming user space behavior.
>
I think you are using the wrong terms here. Flexibility doesn't apply here. What
we are trying to achieve here is to have a generic interface for upper layer
software to manage vgpu device.
> Let me also add some Citrix friends. See how they feel about the necessity of
> having UUID in vgpu name.
Sorry?
Thanks,
Neo
>
> Thanks
> Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Neo Jia <cjia@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Ruan, Shuai" <shuai.ruan@intel.com>,
"Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
qemu-devel <qemu-devel@nongnu.org>,
Alex Williamson <alex.williamson@redhat.com>,
"Paul Durrant (Paul.Durrant@citrix.com)"
<Paul.Durrant@citrix.com>, Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Malcolm Crossley (malcolm.crossley@citrix.com)"
<malcolm.crossley@citrix.com>,
"Lv, Zhiyuan" <zhiyuan.lv@intel.com>
Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.
Date: Wed, 17 Feb 2016 02:34:09 -0800 [thread overview]
Message-ID: <20160217103409.GB11166@nvidia.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F7B674F@SHSMSX101.ccr.corp.intel.com>
On Wed, Feb 17, 2016 at 09:52:04AM +0000, Tian, Kevin wrote:
> > From: Neo Jia [mailto:cjia@nvidia.com]
> > Sent: Wednesday, February 17, 2016 5:35 PM
> >
> > On Wed, Feb 17, 2016 at 08:57:08AM +0000, Tian, Kevin wrote:
> > > > From: Neo Jia [mailto:cjia@nvidia.com]
> > > > Sent: Wednesday, February 17, 2016 3:55 PM
> > >
> > If we can make it free, why not?
>
> I can buy-in this argument.
Great!
>
> Qemu is not a kernel component. And UUID is OPTIONAL for Qemu.
>
> KVM is the kernel component. It doesn't use UUID at all. the relation between
> UUID and VM is fully maintained in user space.
Hold on ... we are talking about the vgpu.ko not KVM right?
UUID is just a generic way to represent an object, here we use a uuid to
represent a virtual gpu device.
>
> >
> > Please also note that using UUID to represent a virtual gpu device directory
> > doesn't mean UUID is part of a GPU resource.
>
> but it adds a hard dependency on another resource - UUID.
>
> >
> > >
> > > So let's keep UUID as an optional parameter. When UUID is provided, it
> > > will be included in the vGPU name then your requirement can be met.
> > >
> >
> > Like I have said before, we are seeking a generic interface to allow upper layer
> > software stack to manage vgpu device for different vendors, so we should not really
> > consider "an optional path for vgpu device discovery" at all.
> >
> > This is why I think we should use this UUID as a generic management interface,
> > and we shouldn't have anything optional.
> >
>
> I don't buy-in this argument. I always think kernel design should provide
> enough flexibility, instead of assuming user space behavior.
>
I think you are using the wrong terms here. Flexibility doesn't apply here. What
we are trying to achieve here is to have a generic interface for upper layer
software to manage vgpu device.
> Let me also add some Citrix friends. See how they feel about the necessity of
> having UUID in vgpu name.
Sorry?
Thanks,
Neo
>
> Thanks
> Kevin
next prev parent reply other threads:[~2016-02-17 10:34 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56AFD231.3010404@nvidia.com>
2016-02-02 1:48 ` [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU Kirti Wankhede
2016-02-02 1:48 ` [Qemu-devel] " Kirti Wankhede
2016-02-02 7:42 ` Tian, Kevin
2016-02-02 7:42 ` [Qemu-devel] " Tian, Kevin
2016-02-02 8:00 ` Gerd Hoffmann
2016-02-02 8:00 ` [Qemu-devel] " Gerd Hoffmann
2016-02-02 8:13 ` Neo Jia
2016-02-02 8:13 ` [Qemu-devel] " Neo Jia
2016-02-02 8:18 ` Tian, Kevin
2016-02-02 8:18 ` [Qemu-devel] " Tian, Kevin
2016-02-02 8:31 ` Neo Jia
2016-02-02 8:31 ` [Qemu-devel] " Neo Jia
2016-02-02 17:11 ` Alex Williamson
2016-02-02 17:11 ` [Qemu-devel] " Alex Williamson
2016-02-03 5:41 ` Tian, Kevin
2016-02-03 5:41 ` [Qemu-devel] " Tian, Kevin
2016-02-03 8:28 ` Gerd Hoffmann
2016-02-03 8:28 ` [Qemu-devel] " Gerd Hoffmann
2016-02-03 19:32 ` Alex Williamson
2016-02-03 19:32 ` [Qemu-devel] " Alex Williamson
2016-02-16 6:49 ` Tian, Kevin
2016-02-16 6:49 ` [Qemu-devel] " Tian, Kevin
2016-02-16 7:13 ` Neo Jia
2016-02-16 7:13 ` [Qemu-devel] " Neo Jia
2016-02-16 7:27 ` Tian, Kevin
2016-02-16 7:27 ` [Qemu-devel] " Tian, Kevin
2016-02-16 7:36 ` Neo Jia
2016-02-16 7:36 ` [Qemu-devel] " Neo Jia
2016-02-16 7:40 ` Tian, Kevin
2016-02-16 7:40 ` [Qemu-devel] " Tian, Kevin
2016-02-16 7:53 ` Neo Jia
2016-02-16 7:53 ` [Qemu-devel] " Neo Jia
2016-02-16 8:10 ` Tian, Kevin
2016-02-16 8:10 ` [Qemu-devel] " Tian, Kevin
2016-02-16 8:48 ` Neo Jia
2016-02-16 8:48 ` [Qemu-devel] " Neo Jia
2016-02-17 3:31 ` Tian, Kevin
2016-02-17 3:31 ` [Qemu-devel] " Tian, Kevin
2016-02-17 4:17 ` Neo Jia
2016-02-17 4:17 ` [Qemu-devel] " Neo Jia
2016-02-17 5:04 ` Tian, Kevin
2016-02-17 5:04 ` [Qemu-devel] " Tian, Kevin
2016-02-17 5:09 ` Eric Blake
2016-02-17 5:40 ` Neo Jia
2016-02-17 5:40 ` Neo Jia
2016-02-17 5:37 ` Neo Jia
2016-02-17 6:02 ` Tian, Kevin
2016-02-17 6:02 ` Tian, Kevin
2016-02-17 7:26 ` Neo Jia
2016-02-17 7:46 ` Tian, Kevin
2016-02-17 7:46 ` Tian, Kevin
2016-02-17 7:54 ` Neo Jia
2016-02-17 8:57 ` Tian, Kevin
2016-02-17 8:57 ` Tian, Kevin
2016-02-17 9:34 ` Neo Jia
2016-02-17 9:52 ` Tian, Kevin
2016-02-17 9:52 ` Tian, Kevin
2016-02-17 10:34 ` Neo Jia [this message]
2016-02-17 10:34 ` Neo Jia
2016-02-17 10:47 ` Tian, Kevin
2016-02-17 10:47 ` Tian, Kevin
2016-02-17 13:08 ` Gerd Hoffmann
2016-02-17 13:08 ` Gerd Hoffmann
2016-02-17 15:36 ` Neo Jia
2016-02-17 15:36 ` Neo Jia
2016-02-17 6:52 ` Gerd Hoffmann
2016-02-17 6:52 ` [Qemu-devel] " Gerd Hoffmann
2016-02-17 7:32 ` Neo Jia
2016-02-17 7:32 ` [Qemu-devel] " Neo Jia
2016-02-17 7:51 ` Tian, Kevin
2016-02-17 7:51 ` [Qemu-devel] " Tian, Kevin
2016-02-17 8:41 ` Neo Jia
2016-02-17 8:41 ` [Qemu-devel] " Neo Jia
2016-02-17 9:01 ` Tian, Kevin
2016-02-17 9:01 ` [Qemu-devel] " Tian, Kevin
2016-02-02 8:29 ` Gerd Hoffmann
2016-02-02 8:29 ` [Qemu-devel] " Gerd Hoffmann
2016-02-02 9:25 ` Kirti Wankhede
2016-02-02 9:25 ` [Qemu-devel] " Kirti Wankhede
2016-02-03 5:56 ` Tian, Kevin
2016-02-03 5:56 ` [Qemu-devel] " Tian, Kevin
2016-02-03 13:21 ` Kirti Wankhede
2016-02-03 13:21 ` [Qemu-devel] " Kirti Wankhede
2016-02-04 3:08 ` Tian, Kevin
2016-02-04 3:08 ` [Qemu-devel] " Tian, Kevin
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=20160217103409.GB11166@nvidia.com \
--to=cjia@nvidia.com \
--cc=Paul.Durrant@citrix.com \
--cc=alex.williamson@redhat.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=malcolm.crossley@citrix.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shuai.ruan@intel.com \
--cc=zhiyuan.lv@intel.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.