On Wed, Feb 17, 2016 at 08:57:08AM +0000, Tian, Kevin wrote: > > From: Neo Jia [mailto:cjia@xxxxxxxxxx] > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
