| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-22 | |||
| 12:02:16 | Dmitrii-Sh | sean-k-mooney: yes, I think there has to be a mapping table somewhere but I haven't quite decided where yet | |
| 12:03:09 | sean-k-mooney | Dmitrii-Sh: in neutron | |
| 12:03:09 | sean-k-mooney | Dmitrii-Sh: in neutron | |
| 12:03:29 | sean-k-mooney | i dont think nova should need to know what network backend is being used in this code | |
| 12:03:29 | sean-k-mooney | i dont think nova should need to know what network backend is being used in this code | |
| 12:03:35 | Dmitrii-Sh | sean-k-mooney: this makes sense. Otherwise Nova becomes too aware of a particular ML2 mechanism driver | |
| 12:03:35 | Dmitrii-Sh | sean-k-mooney: this makes sense. Otherwise Nova becomes too aware of a particular ML2 mechanism driver | |
| 12:03:47 | sean-k-mooney | yep | |
| 12:04:05 | sean-k-mooney | i have only skimmed the spec so i really need to set some time aside to digest it | |
| 12:04:05 | sean-k-mooney | i have only skimmed the spec so i really need to set some time aside to digest it | |
| 12:04:23 | Dmitrii-Sh | sean-k-mooney: ok, np, thanks for the early and quick feedback - much appreciated | |
| 12:04:23 | Dmitrii-Sh | sean-k-mooney: ok, np, thanks for the early and quick feedback - much appreciated | |
| 12:04:39 | Dmitrii-Sh | sean-k-mooney: I am happy to make adjustments to make it work with the ongoing efforts in Nova | |
| 12:04:39 | Dmitrii-Sh | sean-k-mooney: I am happy to make adjustments to make it work with the ongoing efforts in Nova | |
| 12:05:25 | sean-k-mooney | ill try and do that relitively soon. if we dont have time in the ptg we coudl set up a call afterward next week or the week after and see who is interested | |
| 12:05:25 | sean-k-mooney | ill try and do that relitively soon. if we dont have time in the ptg we coudl set up a call afterward next week or the week after and see who is interested | |
| 12:05:36 | sean-k-mooney | Dmitrii-Sh: have you discussed this with the neutron folks yet? | |
| 12:05:36 | sean-k-mooney | Dmitrii-Sh: have you discussed this with the neutron folks yet? | |
| 12:06:24 | Dmitrii-Sh | sean-k-mooney: ty. I think I'm going to hop in during the PCI device tracking in the Placement service discussion (added a note to ping me to the etherpad just in case). | |
| 12:06:24 | Dmitrii-Sh | sean-k-mooney: ty. I think I'm going to hop in during the PCI device tracking in the Placement service discussion (added a note to ping me to the etherpad just in case). | |
| 12:06:35 | Dmitrii-Sh | sean-k-mooney: I am working on a Neutron spec at the moment | |
| 12:06:35 | Dmitrii-Sh | sean-k-mooney: I am working on a Neutron spec at the moment | |
| 12:06:41 | sean-k-mooney | cool | |
| 12:06:41 | sean-k-mooney | cool | |
| 12:06:51 | Dmitrii-Sh | sean-k-mooney: There is some cross-project work to do in Neutron OVN mechanism driver and OVN itself | |
| 12:06:51 | Dmitrii-Sh | sean-k-mooney: There is some cross-project work to do in Neutron OVN mechanism driver and OVN itself | |
| 12:07:38 | sean-k-mooney | by the way one hack for the differnt hostname thing you could look at is changhing the [DEFAULT]/host value in the neutronl.conf for the ovs agent of the hostname value in the ovsdb for ovn | |
| 12:07:38 | sean-k-mooney | by the way one hack for the differnt hostname thing you could look at is changhing the [DEFAULT]/host value in the neutronl.conf for the ovs agent of the hostname value in the ovsdb for ovn | |
| 12:08:36 | sean-k-mooney | basically you could change those values so that you are declaring that you are manaing the network on behalf of host XYZ even if its not running on it | |
| 12:08:36 | sean-k-mooney | basically you could change those values so that you are declaring that you are manaing the network on behalf of host XYZ even if its not running on it | |
| 12:09:06 | Dmitrii-Sh | sean-k-mooney: there's a possibility that there will be 2 SmartNICs in one physical host | |
| 12:09:06 | Dmitrii-Sh | sean-k-mooney: there's a possibility that there will be 2 SmartNICs in one physical host | |
| 12:09:18 | sean-k-mooney | so assuming the agent/ovn would be runnign on the smart nic you could use the servers hostname for those values | |
| 12:09:19 | sean-k-mooney | so assuming the agent/ovn would be runnign on the smart nic you could use the servers hostname for those values | |
| 12:09:20 | Dmitrii-Sh | which creates an issue with this - I considered it as an initial hack | |
| 12:09:20 | Dmitrii-Sh | which creates an issue with this - I considered it as an initial hack | |
| 12:09:34 | sean-k-mooney | ah right | |
| 12:09:42 | sean-k-mooney | ya that does make things harder | |
| 12:09:42 | sean-k-mooney | ya that does make things harder | |
| 12:09:52 | Dmitrii-Sh | sean-k-mooney: hence the dances with PCI VPD serial numbers | |
| 12:09:52 | Dmitrii-Sh | sean-k-mooney: hence the dances with PCI VPD serial numbers | |
| 12:10:08 | Dmitrii-Sh | as we don't have another way of tracking which functions belong where on both sides | |
| 12:10:08 | Dmitrii-Sh | as we don't have another way of tracking which functions belong where on both sides | |
| 12:10:14 | sean-k-mooney | still i think we coudl encode some info in ovn or the agent config such that the ml2 driver could maintain the mapping | |
| 12:10:14 | sean-k-mooney | still i think we coudl encode some info in ovn or the agent config such that the ml2 driver could maintain the mapping | |
| 12:10:38 | sean-k-mooney | it just wont be as simple | |
| 12:10:38 | sean-k-mooney | it just wont be as simple | |
| 12:10:54 | sean-k-mooney | i see one other issue potentaillyu | |
| 12:10:54 | sean-k-mooney | i see one other issue potentaillyu | |
| 12:11:17 | sean-k-mooney | the pci address will it always be the same form the host vs smartnic perspecitve | |
| 12:11:17 | sean-k-mooney | the pci address will it always be the same form the host vs smartnic perspecitve | |
| 12:12:40 | Dmitrii-Sh | Didn't quite catch that. The SmartNIC host sees a different PCIe topology from the hypervisor host | |
| 12:12:40 | Dmitrii-Sh | Didn't quite catch that. The SmartNIC host sees a different PCIe topology from the hypervisor host | |
| 12:12:47 | Dmitrii-Sh | different addresses too | |
| 12:12:47 | Dmitrii-Sh | different addresses too | |
| 12:12:58 | Dmitrii-Sh | basically each host does its own PCIe topology enumeration | |
| 12:12:58 | Dmitrii-Sh | basically each host does its own PCIe topology enumeration | |
| 12:13:34 | Dmitrii-Sh | it's kind of like with blades and non-transparent bridging or managed PCIe switches that hide certain parts of the overall topology | |
| 12:13:34 | Dmitrii-Sh | it's kind of like with blades and non-transparent bridging or managed PCIe switches that hide certain parts of the overall topology | |
| 12:14:17 | sean-k-mooney | right | |
| 12:14:41 | sean-k-mooney | so the only thing that we currently pass to neturon to tell it which device we selected is the pci address | |
| 12:14:41 | sean-k-mooney | so the only thing that we currently pass to neturon to tell it which device we selected is the pci address | |
| 12:14:58 | sean-k-mooney | from the nova-compute agents point of view | |
| 12:14:58 | sean-k-mooney | from the nova-compute agents point of view | |
| 12:15:05 | Dmitrii-Sh | yes, and that's the problem in this case | |
| 12:15:05 | Dmitrii-Sh | yes, and that's the problem in this case | |
| 12:15:23 | Dmitrii-Sh | the ARM host doens't know how the hypervisor host enumerated its topology | |
| 12:15:23 | Dmitrii-Sh | the ARM host doens't know how the hypervisor host enumerated its topology | |
| 12:15:24 | sean-k-mooney | we cannot use macs and other info like vendor id and project id are not applicable | |
| 12:15:24 | sean-k-mooney | we cannot use macs and other info like vendor id and project id are not applicable | |
| 12:15:31 | Dmitrii-Sh | doesn't* | |
| 12:15:31 | Dmitrii-Sh | doesn't* | |
| 12:15:42 | Dmitrii-Sh | sean-k-mooney: yes | |
| 12:15:42 | Dmitrii-Sh | sean-k-mooney: yes | |
| 12:15:45 | sean-k-mooney | yep so we would need the neuron ml2 driver to translate | |
| 12:15:45 | sean-k-mooney | yep so we would need the neuron ml2 driver to translate | |
| 12:16:09 | sean-k-mooney | we could optionally add some addtional info to the binding profile which i assuem is what you were suggesting | |
| 12:16:09 | sean-k-mooney | we could optionally add some addtional info to the binding profile which i assuem is what you were suggesting | |
| 12:16:33 | Dmitrii-Sh | sean-k-mooney: yes, the PCIe VPD serial number could be it. Additionally, we need a way to send a logical number of a VF | |
| 12:16:33 | Dmitrii-Sh | sean-k-mooney: yes, the PCIe VPD serial number could be it. Additionally, we need a way to send a logical number of a VF | |
| 12:16:43 | Dmitrii-Sh | to pick the right representor on the other side | |
| 12:16:43 | Dmitrii-Sh | to pick the right representor on the other side | |
| 12:16:57 | Dmitrii-Sh | the logical numbers are maintained in the NIC firmware, so presumably they are stable | |
| 12:16:57 | Dmitrii-Sh | the logical numbers are maintained in the NIC firmware, so presumably they are stable | |
| 12:17:11 | sean-k-mooney | i think we can discuover both of those statically and put them in the extra_info column | |
| 12:17:11 | sean-k-mooney | i think we can discuover both of those statically and put them in the extra_info column | |
| 12:17:21 | sean-k-mooney | then we can include that in the port update | |
| 12:17:21 | sean-k-mooney | then we can include that in the port update | |
| 12:17:56 | sean-k-mooney | Dmitrii-Sh: i think we can avoid the need for any db schema changes on the nova side | |
| 12:17:56 | sean-k-mooney | Dmitrii-Sh: i think we can avoid the need for any db schema changes on the nova side | |
| 12:18:45 | sean-k-mooney | currently we only use the extra_info column to store nic features. i was going to store vdpa device paths in them but we removed it | |
| 12:18:45 | Dmitrii-Sh | sean-k-mooney: that's one way to do it. I was planning to do the translation based on the relationship of "transport node" RPs (name == VPD serial) and OVN chassis RPs (name == smartnic_hostname). | |
| 12:18:45 | sean-k-mooney | currently we only use the extra_info column to store nic features. i was going to store vdpa device paths in them but we removed it | |
| 12:18:45 | Dmitrii-Sh | sean-k-mooney: that's one way to do it. I was planning to do the translation based on the relationship of "transport node" RPs (name == VPD serial) and OVN chassis RPs (name == smartnic_hostname). | |
| 12:19:22 | Dmitrii-Sh | So, in essence, the Nova schema changes are there to build the Placement state ("transport node" RPs) | |
| 12:19:22 | Dmitrii-Sh | So, in essence, the Nova schema changes are there to build the Placement state ("transport node" RPs) | |
| 12:19:50 | Dmitrii-Sh | I could build this info as devices are discovered and push it to the Placement DB right away | |
| 12:19:50 | Dmitrii-Sh | I could build this info as devices are discovered and push it to the Placement DB right away | |
| 12:20:13 | sean-k-mooney | well what we are going to discsus later is create rp for each PCI device as a chiled of the compute node rp with the pci address as the RP name | |
| 12:20:13 | sean-k-mooney | well what we are going to discsus later is create rp for each PCI device as a chiled of the compute node rp with the pci address as the RP name | |