> From: Neo Jia [mailto:cjia@xxxxxxxxxx] > 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@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? 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 -- 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
