| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-09 | |||
| 11:59:14 | sean-k-mooney | is what marks it as a nic and is required for neutron consumtion | |
| 11:59:40 | sean-k-mooney | im not sure if we explictly prevent alaise form consuming device with physical_network set | |
| 11:59:51 | sean-k-mooney | but we could do that going forward i guess | |
| 11:59:55 | gibi | I think we did not prevent it today | |
| 12:00:03 | sean-k-mooney | ack | |
| 12:00:26 | sean-k-mooney | so for device with physical_network set | |
| 12:00:34 | gibi | we can simply say that resource_class will not be applicable if physical_network tag is present, and nova will use standard RC for these devices | |
| 12:00:46 | sean-k-mooney | i think its fine to mark them as SRIOV_NET_VF or SRIOV_NET_PF | |
| 12:00:49 | gibi | cool | |
| 12:01:01 | sean-k-mooney | we would likely track vdpa devices as SRIOV_NET_VF too | |
| 12:01:16 | sean-k-mooney | although i guess that could be SRIOV_NET_VDPA | |
| 12:01:33 | sean-k-mooney | that actully might make more sense not that i think of it | |
| 12:02:08 | gibi | yeah. but we don't have to decide it now, I just needed to make sure the that the current spec is future proof | |
| 12:02:10 | sean-k-mooney | so yes making RC and phsynet mutally exclsive i think is correct | |
| 12:02:22 | sean-k-mooney | yep | |
| 12:02:30 | gibi | OK | |
| 12:02:31 | gibi | next one | |
| 12:02:39 | sean-k-mooney | so you descoped the current spec to jsut the alias based passthough case yes | |
| 12:02:43 | gibi | yes | |
| 12:02:50 | sean-k-mooney | cool im fine with that by the way | |
| 12:02:53 | gibi | it is still complex enough | |
| 12:03:08 | sean-k-mooney | i want the neutron way to work too but it does not need to be in the initall mvp | |
| 12:03:14 | gibi | I just keep an eye on things not to create a dead end with the current spec | |
| 12:03:22 | sean-k-mooney | yep | |
| 12:03:36 | sean-k-mooney | ok so back ot your next question :) | |
| 12:03:55 | gibi | OK, the next one is simple. With the current proposal the RP is named <hostname>_pci_0000_84_00_0 | |
| 12:04:08 | gibi | if we follow the pGPUnaming | |
| 12:04:11 | gibi | PGPU naming | |
| 12:04:22 | gibi | is that OK? | |
| 12:04:49 | gibi | we could have a full normal PCI address if we want as the RP name charset is not restricted | |
| 12:04:50 | sean-k-mooney | am so i was not planning to use the lable for libvirt | |
| 12:05:13 | sean-k-mooney | the nodedev name pci_0000_84_00_0 | |
| 12:05:19 | sean-k-mooney | is not considerd stable by them | |
| 12:05:30 | gibi | ahh, good to know | |
| 12:05:37 | gibi | then I think it is better not to rely on it | |
| 12:05:39 | sean-k-mooney | so i was thinking it woudl be <hostname>_<pci addres in linux format> | |
| 12:05:47 | gibi | so like in DDDD:BB:AA.FF format? | |
| 12:05:50 | sean-k-mooney | yes | |
| 12:05:57 | gibi | OK, we can do that | |
| 12:06:03 | sean-k-mooney | is : allowed | |
| 12:06:08 | gibi | yes it is | |
| 12:06:17 | gibi | the RP name is free text | |
| 12:06:19 | sean-k-mooney | ok we could normalise | |
| 12:06:24 | sean-k-mooney | if not | |
| 12:06:31 | gibi | the traits and RCs are restricted | |
| 12:06:48 | sean-k-mooney | if we wanted to have pci_0000_84_00_0 by the way i would prefer that nova generated that | |
| 12:06:55 | sean-k-mooney | rahter then using the value directly form libvirt | |
| 12:07:56 | sean-k-mooney | but im oke wiht usei the bdf format above DDDD:BB:AA.FF | |
| 12:08:04 | gibi | ack | |
| 12:08:21 | gibi | next one | |
| 12:08:22 | sean-k-mooney | so one thing related to this | |
| 12:08:29 | gibi | go | |
| 12:08:53 | sean-k-mooney | even if you add the device to the device list using devname instead of the adress we would still use the pci adress in the RP name yes | |
| 12:09:03 | gibi | yes | |
| 12:09:04 | sean-k-mooney | i just want to make sure that detail is hidden form placement | |
| 12:09:06 | sean-k-mooney | cool | |
| 12:09:25 | gibi | if we need the devname for any reason during the scheduling we can add that as a trait | |
| 12:09:51 | sean-k-mooney | yes we could. currently its not used in the alias or pci request object | |
| 12:09:55 | sean-k-mooney | so we shoudl not | |
| 12:10:16 | sean-k-mooney | but if we did a trait woudl be workable | |
| 12:10:55 | gibi | if not needed then we wont add it :) | |
| 12:11:01 | sean-k-mooney | :) | |
| 12:11:03 | gibi | so the next question is related | |
| 12:11:15 | gibi | what traits nova needs to add automatically? | |
| 12:11:30 | gibi | only the ones mentioned in the device_lsit | |
| 12:11:31 | gibi | ? | |
| 12:11:47 | gibi | or we want to automate things like adding capabilities as traits | |
| 12:12:10 | sean-k-mooney | ah so yes the capablitiy traits shoudl be added in my view | |
| 12:12:22 | sean-k-mooney | they were intended to be reported to placement orgianly | |
| 12:12:29 | gibi | OK, that make sense | |
| 12:13:00 | gibi | do we have in the code somewhere listed what are the capabilities we parse? or we parse verything? | |
| 12:13:00 | sean-k-mooney | so if i rememebr correctly you were suggeting allow additivie only traits to be listed in the device_list | |
| 12:13:04 | gibi | *everything | |
| 12:13:16 | sean-k-mooney | gibi: im looking for the code now | |
| 12:13:31 | sean-k-mooney | but we had code to normalise the capablites and report them to placement that ralonsoh wrote in the past | |
| 12:13:33 | gibi | sean-k-mooney: yepp the today spec only supports additive traits | |
| 12:14:45 | sean-k-mooney | https://review.opendev.org/q/topic:bp%252Fenable-sriov-nic-features | |
| 12:15:09 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/466051 specficically | |
| 12:15:18 | sean-k-mooney | but you might be able to reuse some of the other work | |
| 12:16:19 | sean-k-mooney | gibi: the traits have already been added to os-traits https://github.com/openstack/os-traits/blob/master/os_traits/hw/nic/offload.py | |
| 12:17:18 | gibi | thanks, this helps | |
| 12:17:44 | gibi | so lets report capabilities as traits | |
| 12:17:59 | gibi | and then I will amend the spec to allow removing traits via device_list | |
| 12:18:08 | gibi | to disable capability | |
| 12:18:09 | sean-k-mooney | yep. right now this only makes sense for neutron nics really | |
| 12:18:20 | sean-k-mooney | since we dont really gather capablities for other devices | |
| 12:18:30 | gibi | ahh | |
| 12:18:36 | gibi | so no generic PCI caps | |
| 12:18:37 | sean-k-mooney | although remote_mannaged might be the excption | |
| 12:18:56 | sean-k-mooney | well for the remote managed deviecs we now have the vpd | |
| 12:18:57 | sean-k-mooney | capablity | |
| 12:19:17 | sean-k-mooney | that is not yet a trait so maybe we would want to report that | |
| 12:19:48 | sean-k-mooney | gibi: i think for the inital version we could keep it to jsut operator provided traits | |
| 12:19:54 | sean-k-mooney | if we want to keep it simple | |
| 12:20:33 | sean-k-mooney | then in the future we can auto discover device capablities and report them if that makes sense | |
| 12:20:44 | gibi | yeah that make sense, it is easy to add later | |
| 12:20:57 | gibi | so keeping traits just additive now as well | |
| 12:21:58 | gibi | OK | |
| 12:22:21 | gibi | next one | |
| 12:22:23 | gibi | https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#288 | |