Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Tian, Kevin]

> From: Neo Jia [mailto:address@hidden
> 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:address@hidden
> > > Sent: Wednesday, February 17, 2016 3:55 PM
> >
> > 'whoever' is too strict here. I don't think UUID is required in all 
> > scenarios.
> >
> > In your scenario:
> >
> > - You will pass VM UUID when creating a vgpu.
> > - Consequently a /sys/device/virtual/vgpu/$UUID-$vgpu-id is created
> > - Then you can identify $UUID-$vgpu-id is right for the very VM, by matching
> > all available vgpu nodes with VM UUID;
> >
> > When it is a bit convenient, I don't see it significant. Looping directory 
> > is
> > not unusual for file/directory operations and it happens infrequently only
> > for vgpu life-cycle mgmt..
> 
> Hi Kevin,
> 
> The search is expensive, when you have 8 physical gpus and each can support up
> to 32 vgpus. vgpu life-cycle management happens a lot as well in real 
> production
> scenario.
> 
> If we can make it free, why not?

I can buy-in this argument.

> 
> >
> > Please think about my original proposal carefully. I'm not opposing encoding
> > UUID in vgpu name. What I'm opposing is not to make it mandatory, i.e. when
> > UUID is not provided, we should still allow vgpu creation using some default
> > descriptive string.
> 
> Probably you are not quite get the generic design that we are proposing here.
> 
> The goal here is to have a unified interface for all gpu vendor, and expose 
> that
> to the upper layer software stack, so I don't think we should have an optional
> vgpu device discovery path at all.
> 
> If we have an optional case, does that mean libvirt will have a different
> implementation and qemu will have a different implementation? I don't think 
> that
> is acceptable.

libvirt can choose to always provide UUID, then there's no problem. Another
stack can choose to not use UUID. It doesn't mean each stack needs to support
different implementation. Just from kernel p.o.v we need sustain such 
flexibility.

Qemu will always have the same implementation. I explained this multiple
times. Qemu only cares about a sysfsdev path parameter. It doesn't
matter whether it has a UUID included or not.

> 
> Since you have admitted this design is convenient and performance better, I 
> think we
> should stay with it.
> 
> >
> > 'user space dependency' means you need additional user-space operations
> > (say uuidgen here) before you can utilize GPU virtualization feature, which
> > is not necessary. In reality, UUID is not a GPU resource. It's not what GPU
> > virtualization intrinsically needs to handle. Let's keep vGPU-core 
> > sub-system
> > modulo for its real functionalities.
> 
> Don't you need to create UUID to make qemu happy? I don't get this argument.

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.

> 
> 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.

Let me also add some Citrix friends. See how they feel about the necessity of
having UUID in vgpu name.

Thanks
Kevin