Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-01
13:31:59 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290
13:33:53 fried_rice What's ironic's nova CI called?
13:34:48 leakypipes PapaOurs: that mdev_supported_types is nothing more than a reference to NVIDIA's product names.
13:34:53 sususuryashines dansmith, hansmoleman: would like your opinion on https://review.openstack.org/#/c/560042/ whenever you have the time.
13:35:18 dansmith this sounds like a job for...
13:35:46 jroll fried_rice: something-ironic-something :P
13:36:02 jroll ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa
13:36:08 fried_rice oh, there it is.
13:36:11 fried_rice thanks jroll
13:36:15 jroll np
13:36:24 MurderTheLeafBlo damn restrictions on nick length.
13:36:31 jroll heh
13:37:12 fried_rice leakypipes: DieLeafBlowerDie ought to fit
13:37:53 leakypipes fried_rice: oooh, nice.
13:40:47 hansmoleman sususuryashines: only temporary
13:40:56 hansmoleman i'm actually allergic to fun
13:40:59 openstackgerrit Tsuyoshi Nagata proposed openstack/nova master: nova improvement of maximum attach volumes more than 26 vols https://review.openstack.org/567472
13:41:42 sususuryashines hansmoleman: :P
13:42:54 hansmoleman finucannot: thanks, +2
13:43:06 hansmoleman superdan: +2 on finucannot's numa-aware vswitch spec now https://review.openstack.org/#/c/541290/
13:43:33 finucannot hansmoleman: Thanks, appreciate it
13:45:24 PapaOurs leakypipes: "you make sure the "mdev_supported_types" node with differenct vgpu type existed(The "V#ID" represent the corresponding platform, "V4" means it is "Broadwell" platform, "V5" means it is "Skylake" or "Kabylake" platform)"
13:45:55 PapaOurs leakypipes: unless I'm misunderstanding the above, but it's related to an Intel thing, right?
13:46:51 PapaOurs leakypipes: and yet again, it's a VFIO abstraction
13:47:09 PapaOurs leakypipes: why should we call it 'nvidia' even if the nvidia folks provided it ?
13:47:30 PapaOurs it's like if we would say that a libvirt feature supported by the Nova API is only a 'libvirt' one
13:47:58 PapaOurs it could be a Xen or VMWare feature if the virt driver supports it
13:48:04 leakypipes PapaOurs: they *are* the libvirt ones.
13:49:09 leakypipes PapaOurs: I'm not saying we should be leaking vendor details out of the user-facing API. I'm just saying when referring to "vGPU types", we should be honest about it and say what we mean, which is "the NVIDIA vendor model for this NVIDIA pGPU".
13:49:13 hansmoleman is cdent out this week?
13:49:37 leakypipes hansmoleman: I'm not sure. I've seen him on ML off and on. not much on IRC.
13:49:57 figleaf hansmoleman: he's at the vmware mother ship, so I'm sure his attention is spread thin
13:50:32 hansmoleman ah ok
13:50:47 hansmoleman gonna setup a 100 node fake devstack env for some scheduler perf testing, i knew he did something like this before
13:51:02 leakypipes PapaOurs: btw, where is Bauwser? :)
13:51:22 leakypipes hansmoleman: placecat.
13:51:44 hansmoleman i don't need to test placement
13:51:48 leakypipes hansmoleman: https://github.com/cdent/placecat/ maybe what you were thinking?
13:51:50 fried_rice hansmoleman: He has some fairly detailed step-by-step on his blog. Let me know if you want me to dig that up.
13:52:17 hansmoleman fried_rice: yeah i've seen that one before, i think i've got this, it's basically (1) fake virt driver (2) noop quota and (3) NUMBER_FAKE_NOVA_COMPUTE=x
13:52:34 hansmoleman i'm going to try and test before and after https://review.openstack.org/#/c/569247/
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

Earlier   Later