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

[Neo Jia]

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?

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

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.

Please also note that using UUID to represent a virtual gpu device directory
doesn't mean UUID is part of a GPU resource.

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

Thanks,
Neo

> Thanks
> Kevin