| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-01 | |||
| 13:52:45 | hansmoleman | with 100 nodes, 1000 instances, 10 per node | |
| 13:53:08 | PapaOurs | leakypipes: but again, looks like Intel have multiple types, where each of them about an Intel platform | |
| 13:53:30 | leakypipes | PapaOurs: show me. everything I see in their docs refers to NVIDIA vGPU types. | |
| 13:53:37 | superdan | hansmoleman: finucannot I still have questions in there, maybe hansmoleman can clear it up for me if he gets it and I'm just slow | |
| 13:54:00 | leakypipes | PapaOurs: and GVT-g, GVT-d, GVT-s are not different vGPU typoes. | |
| 13:54:03 | PapaOurs | leakypipes: tbh, I need to get an Intel GVT-g hardware | |
| 13:54:06 | ralphlauren | Look up his real name | |
| 13:54:19 | PapaOurs | leakypipes: GVT-g is for vGPUs | |
| 13:54:32 | PapaOurs | GVT-d and GVT-s are different features | |
| 13:54:54 | leakypipes | PapaOurs: yes, I know. and I don't see any evidence that they use vGPU types for aniything other than referencing NVIDIA's vendor model names. | |
| 13:54:58 | PapaOurs | and Intel GVT-g for KVM is also called KVMGT | |
| 13:55:06 | leakypipes | yes, I know that. | |
| 13:55:59 | PapaOurs | leakypipes: you've seen my link ? https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#51-check-mdev-module-kvmgt-only | |
| 13:56:36 | leakypipes | PapaOurs: yes. | |
| 13:56:55 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Add multiqueue port profile for VIFGeneric https://review.openstack.org/570959 | |
| 13:57:00 | PapaOurs | PapaOurs: so, looks like to me there are multiple types for each pGPU | |
| 13:57:10 | PapaOurs | even for an Intel's one | |
| 13:57:18 | leakypipes | 915-GVTg_V5_4 is a driver. | |
| 13:57:32 | PapaOurs | because when creating the mdev, you need to tell which type to use | |
| 13:57:43 | leakypipes | It's Not A Tumor! | |
| 13:57:57 | openstackgerrit | Jan Gutter proposed openstack/nova master: Use vif.vif_name in _set_config_VIFGeneric https://review.openstack.org/571461 | |
| 13:57:58 | openstackgerrit | Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325 | |
| 13:57:59 | openstackgerrit | Jan Gutter proposed openstack/nova master: Pass virtio multiqueue info to os-vif plugins https://review.openstack.org/571462 | |
| 13:58:25 | PapaOurs | leakypipes: i915-GVTg_V5_1 is one type, i915-GVTg_V5_2 is another type | |
| 13:59:14 | leakypipes | PapaOurs: it isn't though... | |
| 13:59:30 | PapaOurs | from a VFIO arch, it is | |
| 13:59:38 | leakypipes | PapaOurs: they are just trying to pidgeonhole their driver info into the NVIDIA mdev framework :( | |
| 13:59:50 | PapaOurs | LOL | |
| 14:00:04 | superdan | mdev is a linux kernel abstraction, right? | |
| 14:00:10 | leakypipes | it's all a load of hardware-specific bullshit, IMHO. | |
| 14:00:20 | leakypipes | superdan: some call it that. | |
| 14:01:12 | PapaOurs | leakypipes: I mean, I understand your point | |
| 14:01:21 | PapaOurs | I'm not saying vendors don't do bullshit | |
| 14:01:35 | PapaOurs | (heh, use of a double negative /o\) | |
| 14:02:02 | PapaOurs | but, the fact is, for the good or worst, they use the VFIO mdev abstraction exactly like nvidia does | |
| 14:02:37 | leakypipes | PapaOurs: "better or worse" :) | |
| 14:03:06 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Test Compute API in multiple cells https://review.openstack.org/547273 | |
| 14:03:52 | PapaOurs | leakypipes: I'm now called PapaOurs, it's making clear that I'm French now :p | |
| 14:03:53 | leakypipes | well, I can agree with you on at least one thing, PapaOurs... | |
| 14:03:58 | cfriesen | PapaOors: I thought AMD used SRIOV | |
| 14:04:08 | leakypipes | PapaOurs: it certainly would be nice to afford to play with some of these things in real life. | |
| 14:04:21 | PapaOurs | leakypipes: that's in my todo list :) | |
| 14:04:25 | leakypipes | cfriesen: oh, hai Chris. welcome to our own private hell. | |
| 14:05:00 | PapaOurs | cfriesen: excellent point | |
| 14:05:32 | PapaOurs | cfriesen: if an hardware vendor doesn't use the VFIO mdev interface with its kernel driver, then sure, vGPUs aren't supported | |
| 14:06:27 | PapaOurs | cfriesen: they can use a different arch, like SR-IOV, but then it's very different | |
| 14:06:47 | leakypipes | I'm a mushroom cloud layin' motherf**ker. | |
| 14:07:47 | cfriesen | I've been following the vGPU stuff only casually, but it sure looks like a pain. :) | |
| 14:10:02 | leakypipes | elbragstad: just sayin' Vincent, I'm Superfly TNT. | |
| 14:11:23 | giblet | fried_rice: I've fixed as much as I can from your comments in https://review.openstack.org/#/c/569417 | |
| 14:11:36 | PapaOurs | cfriesen: the real question is, why a separate vendor doesn't use the kernel interface for that ? | |
| 14:11:39 | leakypipes | cfriesen: here's the thing... it actually *wouldn't* be a pain, IMHO, if we just called a spade a spade and carved out a vendor-specific part of the codebase for Intel and NVIDIA to dump their code into and then we required them to simply hand us a library whose sole purpose was to contain a dict, keyed by their product IDs, containing a list of standardized capabilitiies for each of their products. | |
| 14:12:03 | leakypipes | cfriesen: oh, and have them write meaningful, understandable documentation for their products *before* releasing them. | |
| 14:12:11 | fried_rice | giblet: ack | |
| 14:12:12 | hansmoleman | superdan: good questions, i dropped my +2 and left some replies, finucannot fyi | |
| 14:12:20 | PapaOurs | leakypipes: that was your second concern in my spec, and we could somehow *do* that, but looks to me that's just going to be a hecking thing to update | |
| 14:12:24 | finucannot | hansmoleman: (y) | |
| 14:12:43 | leakypipes | PapaOurs: "heck of a thing"? :) | |
| 14:13:00 | PapaOurs | leakypipes: I can imagine a shit number of nvidia folks coming by nova and asking us to merge their change just for updating that module | |
| 14:13:10 | leakypipes | hehe | |
| 14:13:13 | PapaOurs | leakypipes: we could do a lib tho | |
| 14:13:21 | PapaOurs | but the problem remains | |
| 14:13:27 | leakypipes | PapaOurs: I hope you know I'm just "pulling your chain" on your English phrases. :) | |
| 14:13:33 | leakypipes | it's Friday after all. | |
| 14:13:49 | PapaOurs | leakypipes: and yeah, I don't disagree with you on the poor abstraction that only relies on strings that are defined by the vendor, hence not versioned | |
| 14:14:03 | PapaOurs | leakypipes: I don't take any offense here, no worries ;) | |
| 14:14:18 | PapaOurs | and again, I now officially claim the French verbage | |
| 14:14:27 | leakypipes | :) | |
| 14:15:00 | PapaOurs | leakypipes: so, yeah, I can't argue with you on the fact types are just poorly defined by vendors | |
| 14:15:34 | PapaOurs | the best of that is that's a mandate for keeping those type names identical across releases | |
| 14:16:03 | PapaOurs | so, say, if nvidia wants to rename nvidia-35 type name into something like "M60-8G-MY_SUPER-TYPE", they would be able | |
| 14:16:20 | leakypipes | PapaOurs: well, since they only started doing any of this back in like April last year, we'll just have to wait and see if they completely change the interface here in the next year or so. My bet is, of course they will. | |
| 14:16:29 | PapaOurs | because the kernel directly takes the names straight for the kernel module... | |
| 14:16:38 | PapaOurs | froù | |
| 14:16:40 | PapaOurs | from* | |
| 14:16:46 | leakypipes | I liked frou better. | |
| 14:17:10 | PapaOurs | so, yeah, you can see me sometimes ranting on that btw. | |
| 14:17:43 | PapaOurs | but back to the spec, the only abstraction we have is that poorly-defined-tho-mandatory-and-alone interface that we call 'mdev_supported_types' | |
| 14:17:57 | PapaOurs | good luck with that | |
| 14:18:20 | leakypipes | "standardized pointer to randomness". | |
| 14:19:30 | PapaOurs | leakypipes: that quote is awesome | |
| 14:19:51 | fried_rice | giblet: +1, nice. | |
| 14:19:57 | giblet | fried_rice: thanks | |
| 14:19:58 | ralphlauren | Where did I see a hard_dict? | |
| 14:20:08 | PapaOurs | leakypipes: and now, you guess why QEMU folks push back the nvidia implementation for live migration | |
| 14:20:27 | ralphlauren | I definitely saw a hard_dict somewhere | |
| 14:20:35 | PapaOurs | leakypipes: b/c nvidia just wants to live migrate based on foobar capabilities they solely define and expose | |
| 14:22:23 | PapaOurs | anyway, I need to drop | |
| 14:30:21 | hansmoleman | leakypipes: dan akroyd had a bag-o-glass, i've got a bag-o-dicts | |
| 14:32:23 | openstackgerrit | Merged openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 14:56:32 | openstackgerrit | Tsuyoshi Nagata proposed openstack/nova master: nova improvement of maximum attach volumes more than 26 vols https://review.openstack.org/567472 | |
| 15:05:24 | PapaOurs | leakypipes: hmmm, so I looked at some GVT-g links and that one looks good https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-new-architecture-introduction-update | |
| 15:05:49 | PapaOurs | they say they still use "mdev_supported_types" | |
| 15:06:14 | PapaOurs | leakypipes: so, I'll modify my spec for saying which hardware vendors support mdevs | |
| 15:06:18 | hansmoleman | woot another one bites the dust https://blueprints.launchpad.net/nova/+spec/sriov-trusted-vfs | |
| 15:06:27 | PapaOurs | ie. Intel and Nvidia | |
| 15:07:28 | fried_rice | Do "we" have any interest in, or strong objections to, allowing unicode characters in metadata/extra_specs keys? | |
| 15:12:26 | fried_rice | hansmoleman, superdan: ^ ? | |
| 15:13:15 | leakypipes | fried_rice: 💩 | |
| 15:13:25 | superdan | I thought we already said no unicode there, | |