| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-25 | |||
| 14:44:17 | efried | ? | |
| 14:44:35 | efried | no lo veo | |
| 14:44:37 | claudiub | so, then, you can still request PCI devices through other means, like vendor_id / product_id, or other fields like this? i didn't see this documented. | |
| 14:44:58 | claudiub | not counting sr-iov. | |
| 14:45:19 | claudiub | that's requested whenever a port is vnic_type direct or something similar | |
| 14:45:34 | efried | oh, that. | |
| 14:45:54 | claudiub | that's requested automatically * | |
| 14:45:56 | efried | That's done based on the physical_network tag in the passthrough_whitelist, I believe. Aliases are not involved at all in that flow. | |
| 14:46:11 | claudiub | efried: yeah | |
| 14:46:12 | efried | which is... goofy. | |
| 14:46:38 | efried | Hey, it's Friday. | |
| 14:47:19 | fried_rice | Yeah, handling SR-IOV is a separate can of worms. | |
| 14:47:48 | fried_rice | And btw, I think SR-IOV is where a lot of the /sys/bus business comes into play. Or rather, why it's there in the first place. | |
| 14:47:55 | claudiub | oh yeah. which reminds me. i didn't find a proper way to "associate" different SR-IOV NICs to different "physical_networks" | |
| 14:48:28 | fried_rice | claudiub How so? | |
| 14:48:44 | fried_rice | oh, the thing where you can only actually have one physical network | |
| 14:49:20 | fried_rice | Yeah, there's a limitation in the binding metadata in neutron. We tried to "fix" it in I think ocata, but armax shot us down. | |
| 14:49:38 | armax | fried_rice: what did I do? | |
| 14:49:49 | fried_rice | armax :) Hold on, let me see if I can dig it up. | |
| 14:50:24 | fried_rice | armax I think it was this one: https://review.openstack.org/#/c/358125/ | |
| 14:50:25 | armax | I don’t typically shoot people down without proper justification :) | |
| 14:50:58 | fried_rice | https://bugs.launchpad.net/neutron/+bug/1615128 | |
| 14:50:59 | openstack | Launchpad bug 1615128 in neutron "Custom binding:profile values not coming through" [Undecided,Invalid] - Assigned to Eric Fried (efried) | |
| 14:51:04 | fried_rice | Oh, you provided justification | |
| 14:51:08 | fried_rice | And we backed off accordingly. | |
| 14:51:37 | jaypipes | fried_rice: apologies, I was wrong on the pci_passthrough + alias thing. :( | |
| 14:51:54 | armax | fried_rice: right, I remember this now…I suppose the next step from the -2 was to follow up with an RFE that never came | |
| 14:52:05 | armax | iirc | |
| 14:52:25 | fried_rice | armax That sounds right. | |
| 14:52:44 | fried_rice | armax Wasn't trying to bust your chops :) | |
| 14:52:53 | armax | fried_rice: so I only injured you, not shot you down mortally :) | |
| 14:53:28 | armax | fried_rice: not a problem, I make mistakes of judment all the time, I was just trying to figure out the context | |
| 14:53:35 | claudiub | fried_rice: hm, simply because the limitation of the passthrough_whitelist config option. I can't reliably get a vendor_id / product_id for the NICs I have, and I can't use the address field either. IMO, if device_id would be allowed, it would work. | |
| 14:53:56 | fried_rice | claudiub Well | |
| 14:53:57 | claudiub | hm, haven't tried devname though. | |
| 14:54:08 | fried_rice | claudiub I haven't actually found any reason you can't spoof the vendor/product ID. | |
| 14:54:20 | fried_rice | I don't *think* those are actually checked against anything real, ever. | |
| 14:54:54 | fried_rice | They're just correlated among the passthrough_whitelist (compute conf), the pci_passthrough_devices (compute-provided get_available_resource), and the alias list (api conf). | |
| 14:54:57 | claudiub | the PCI devices reported by the compute drivers have to have those vendor_id / product_ids | |
| 14:55:27 | fried_rice | Yes, have to have them, but I don't think anything cares that those values are really what the dev reports. | |
| 14:55:45 | claudiub | true. | |
| 14:56:09 | fried_rice | I'm... sort of counting on it, actually. Cause I have a vendor ID, but I'm not sure if the thing I'm using as a product ID is really a product ID. | |
| 14:56:24 | fried_rice | https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/host.py@111 | |
| 14:56:59 | claudiub | for sr-iov devices, i'm currently doing an md5, if i can't get the actual vendor_id, product_id, which feels wrong. :) | |
| 14:57:00 | fried_rice | Course, if you do that (or really, whatever you do), you have to document how your user needs to glean the right value to put in those spots in the whitelist/alias. | |
| 14:57:11 | fried_rice | claudiub Totally | |
| 14:57:16 | fried_rice | I feel your pain. | |
| 14:57:43 | fried_rice | claudiub I'm doing something similar with PCI addresses: https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/vm.py@884 | |
| 14:58:05 | claudiub | *ahem*, if only we could also whitelist via device_id, that would work for me. would it work for you as well? | |
| 14:58:25 | fried_rice | claudiub Where device_id can be an arbitrary string, yes, totally. | |
| 14:59:32 | fried_rice | claudiub In order to do wildcarding, though, you would need to outsource the validation/filtering to the compute driver. | |
| 14:59:46 | fried_rice | Cause he's the only guy who knows how to interpret that "arbitrary" format. | |
| 15:00:17 | fried_rice | Otherwise you would just get a straight string match, which means you have to enumerate every device (or continue to use classes via vendor/prod IDs) | |
| 15:02:05 | fried_rice | claudiub What does the flavor side look like in that case? | |
| 15:02:17 | claudiub | fried_rice: for sr-iov you mean? | |
| 15:02:20 | fried_rice | I don't like the idea of having a flavor that specifies individual devices | |
| 15:02:40 | claudiub | fried_rice: or normal pci devices | |
| 15:02:54 | fried_rice | Let's go normal PCI for now. | |
| 15:03:46 | claudiub | fried_rice: it should still look the same: pci_passthrough:alias=<alias>:<count> | |
| 15:04:16 | fried_rice | so you're adding "device_id" as an alternative to vendor_id/product_id in the alias? | |
| 15:04:39 | claudiub | fried_rice: for sr-iov, the flavor doesn't change, only the neutron port's vnic_type has to bbe direct or something similar, and your ML2 mechanism_driver must be able to support it. | |
| 15:04:53 | fried_rice | Gobackgoback | |
| 15:04:59 | fried_rice | What does that alias look like? | |
| 15:05:10 | claudiub | for sr-iov, you don't need an alias | |
| 15:05:32 | claudiub | you only alias normal pci devices. | |
| 15:05:35 | fried_rice | Yeah, regular PCI devices. Cause if it's just [pci]alias = {"device_id": "1234"} - then you're effectively specifying one device per alias. | |
| 15:06:10 | fried_rice | and you might as well use extra_specs pci_passthrough:device_id:1234 rather than bothering with an alias entry. | |
| 15:07:13 | stephenfin | dansmith: Any chance you could take a look at https://review.openstack.org/#/c/496605/? Think it might be a good backport candidate | |
| 15:07:32 | stephenfin | the follow-up patch probably needs a little more discussion yet | |
| 15:07:36 | claudiub | fried_rice: well, tbh, for normal PCI devices, vendor_id / product_ids are always there on hyper-v. so, that can be used for aliasing. but IMO, a device_id should also be supported. | |
| 15:08:09 | fried_rice | So how would you do that? Perhaps something like [pci]alias = {"name": "foo", "devices": [{"device_id": "abc"}, {"device_id": "123"}, {"vendor_id": "1f2e", "product_id": "a9b8"}]} ? | |
| 15:08:10 | claudiub | fried_rice: yeah, you're right | |
| 15:08:31 | fried_rice | I.e. you can specify a list of stuff to an alias, that allows you to enumerate several devices by ID and/or clasess by prod/vendor? | |
| 15:08:35 | fried_rice | That would be... kinda cool. | |
| 15:09:28 | fried_rice | Even without the ability to specify device IDs in there, if I want to be able to group different prod/vendor types together under a single alias... | |
| 15:09:53 | fried_rice | Like maybe I only care if I get a GPU. Any GPU will do. So make an alias grouping with these vendor/product IDs that all represent GPUs. | |
| 15:12:36 | dansmith | stephenfin: why are you not just doing the conf deprecation now? | |
| 15:13:11 | stephenfin | dansmith: I want to backport the change. Backporting a deprecation seems wrong | |
| 15:13:25 | stephenfin | Same reason I've kept the deprecation timeline so generic | |
| 15:13:30 | dansmith | stephenfin: ah right okay | |
| 15:13:49 | dansmith | stephenfin: why no tests? | |
| 15:14:29 | dansmith | should be pretty easy to write one to make sure we skip that bit... | |
| 15:14:33 | stephenfin | Damn. Because I was cheating :( | |
| 15:14:46 | kashyap | stephenfin: :P | |
| 15:15:01 | kashyap | stephenfin: I noticed the "no tests" thing, but thought you intentionally skipped them with good reason | |
| 15:15:49 | dansmith | stephenfin: I missed the deprecation patch after this, which makes sense.. | |
| 15:16:23 | fried_rice | claudiub Would you be interested in co-authoring/sponsoring a bp to allow whitelisting & aliasing by device ID? | |
| 15:16:26 | stephenfin | dansmith: Yup, that one apparently needs a little more discussion. Key mappings are a minefield | |
| 15:16:56 | claudiub | fried_rice: well, tbh, a device_id would work in sr-iov usecase. that device_id would represent the NIC to which the VFs belong to. thus, I'd have N VFs grouped under the same device_id, which can be aliased as well. | |
| 15:16:56 | stephenfin | fried_rice, claudiub: Stick me on the review if you do author such a bp/spec | |
| 15:17:16 | fried_rice | stephenfin ack | |
| 15:17:25 | claudiub | ould work in my sr-iov usecase * | |
| 15:17:42 | fried_rice | claudiub "under the same device_id" ?? | |
| 15:17:55 | dansmith | stephenfin: doesn't that have an impact on whether or not just unsetting it is the right path in the bottom patch? | |
| 15:18:15 | fried_rice | claudiub oh, what the concept of parent_addr handles today. | |
| 15:18:20 | dansmith | stephenfin: your bottom patch says it's only for curses-based interaction or whatever, but that reviewer onthe deprecation patch seems to think it matters? | |
| 15:18:21 | stephenfin | Not really. We're not actually unsetting it in the bottom patch. Only allowing it to be unset | |
| 15:18:29 | dansmith | sure, but.. | |
| 15:18:49 | claudiub | fried_rice: oh yeah, something like that. | |
| 15:19:14 | stephenfin | ...and that entire first paragraph is essentially taken from danpb's comments on the bug | |