| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-22 | |||
| 11:57:25 | sean-k-mooney | Dmitrii-Sh: im not really trielled with nova calling neutron as part fo vif plugging as a clinet | |
| 11:57:31 | sean-k-mooney | even if that was doen via os-vif | |
| 11:57:31 | Dmitrii-Sh | artom: ack, will do. I understand that it's a lot of info to process | |
| 11:57:31 | sean-k-mooney | even if that was doen via os-vif | |
| 11:57:31 | Dmitrii-Sh | artom: ack, will do. I understand that it's a lot of info to process | |
| 11:58:07 | sean-k-mooney | Dmitrii-Sh: have you spoken to the cyborg team about this by the way | |
| 11:58:07 | sean-k-mooney | Dmitrii-Sh: have you spoken to the cyborg team about this by the way | |
| 11:58:34 | sean-k-mooney | they were tryign to enable reprogrambel smart nics via a different approch | |
| 11:58:34 | sean-k-mooney | they were tryign to enable reprogrambel smart nics via a different approch | |
| 11:58:50 | Dmitrii-Sh | sean-k-mooney: I've seen their specs but they seem to be targeting FPGA-based on-path NICs (Intel IIRC) | |
| 11:58:50 | Dmitrii-Sh | sean-k-mooney: I've seen their specs but they seem to be targeting FPGA-based on-path NICs (Intel IIRC) | |
| 11:59:10 | Dmitrii-Sh | and the approach there is to program NICs from the hypervisor host itself | |
| 11:59:10 | Dmitrii-Sh | and the approach there is to program NICs from the hypervisor host itself | |
| 11:59:11 | sean-k-mooney | Dmitrii-Sh: primarally | |
| 11:59:11 | sean-k-mooney | Dmitrii-Sh: primarally | |
| 11:59:26 | sean-k-mooney | i just wanted to make sure you were aware of it | |
| 11:59:26 | sean-k-mooney | i just wanted to make sure you were aware of it | |
| 11:59:27 | Dmitrii-Sh | where as here there is a security boundary between the hypervisor host and the SmartNIC host | |
| 11:59:27 | Dmitrii-Sh | where as here there is a security boundary between the hypervisor host and the SmartNIC host | |
| 12:00:01 | sean-k-mooney | so there was an effort to allow the neutron agent to manage remote host in the past | |
| 12:00:01 | Dmitrii-Sh | sean-k-mooney: ack, I am. I wish it addressed the things needed for off-path NICs to avoid fragmentation | |
| 12:00:01 | sean-k-mooney | so there was an effort to allow the neutron agent to manage remote host in the past | |
| 12:00:01 | Dmitrii-Sh | sean-k-mooney: ack, I am. I wish it addressed the things needed for off-path NICs to avoid fragmentation | |
| 12:00:08 | sean-k-mooney | what you are proposing is closer to that | |
| 12:00:08 | sean-k-mooney | what you are proposing is closer to that | |
| 12:00:37 | sean-k-mooney | i think we would still want to keep the binding host the same at the ml2 level | |
| 12:00:37 | sean-k-mooney | i think we would still want to keep the binding host the same at the ml2 level | |
| 12:00:44 | sean-k-mooney | the host on which the vm resides | |
| 12:00:44 | sean-k-mooney | the host on which the vm resides | |
| 12:00:53 | Dmitrii-Sh | There was some work in Ironic in the past https://specs.openstack.org/openstack/ironic-specs/specs/approved/support-smart-nic.html | |
| 12:00:53 | Dmitrii-Sh | There was some work in Ironic in the past https://specs.openstack.org/openstack/ironic-specs/specs/approved/support-smart-nic.html | |
| 12:01:03 | sean-k-mooney | but we may need to have other information that woudl be use to corralate that to the chassis in ovn | |
| 12:01:03 | sean-k-mooney | but we may need to have other information that woudl be use to corralate that to the chassis in ovn | |
| 12:01:31 | Dmitrii-Sh | as a result neutron-openvswitch-agent started using os-vif to plug representors (but that's not usable outside ironic at the moment) | |
| 12:01:31 | Dmitrii-Sh | as a result neutron-openvswitch-agent started using os-vif to plug representors (but that's not usable outside ironic at the moment) | |
| 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: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 | |