| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-28 | |||
| 09:23:04 | stephenfin | bauzas: Are you okay with me addressing your nits and then reviewing https://review.opendev.org/c/openstack/nova/+/695012 myself? I think the bulk of the change will stay the same | |
| 09:23:04 | stephenfin | bauzas: Are you okay with me addressing your nits and then reviewing https://review.opendev.org/c/openstack/nova/+/695012 myself? I think the bulk of the change will stay the same | |
| 09:23:47 | bauzas | stephenfin: woah, long story here, I can't remember the context but sure | |
| 09:23:47 | bauzas | stephenfin: woah, long story here, I can't remember the context but sure | |
| 09:24:42 | sean-k-mooney | we really should try and get that serise merged | |
| 09:24:42 | sean-k-mooney | we really should try and get that serise merged | |
| 09:26:45 | sean-k-mooney | hum i wonder why i never left any review comments on that unless its a different seriese form mark | |
| 09:26:45 | sean-k-mooney | hum i wonder why i never left any review comments on that unless its a different seriese form mark | |
| 09:29:56 | sean-k-mooney | oh i was thinking of https://review.opendev.org/c/openstack/nova/+/710848 https://review.opendev.org/c/openstack/nova/+/710847 and https://review.opendev.org/c/openstack/nova/+/760354 | |
| 09:29:56 | sean-k-mooney | oh i was thinking of https://review.opendev.org/c/openstack/nova/+/710848 https://review.opendev.org/c/openstack/nova/+/710847 and https://review.opendev.org/c/openstack/nova/+/760354 | |
| 09:50:38 | stephenfin | gibi: Could I get you to review the small diff on https://review.opendev.org/c/openstack/nova/+/676209 yet again, please? /o\ | |
| 09:50:38 | stephenfin | gibi: Could I get you to review the small diff on https://review.opendev.org/c/openstack/nova/+/676209 yet again, please? /o\ | |
| 09:51:01 | stephenfin | lyarwood: Any chance you'd be able to slog through that so I can finally close it out? I genuinely think it's a useful addition | |
| 09:51:01 | stephenfin | lyarwood: Any chance you'd be able to slog through that so I can finally close it out? I genuinely think it's a useful addition | |
| 09:58:12 | lyarwood | stephenfin: yup I'll queue it up for later today if that's okay | |
| 09:58:12 | lyarwood | stephenfin: yup I'll queue it up for later today if that's okay | |
| 09:58:22 | stephenfin | wfm. Thanks | |
| 09:58:22 | stephenfin | wfm. Thanks | |
| 09:58:32 | lyarwood | stephenfin: and I'll likely ask for the same later in the cycle for the block layer | |
| 09:58:33 | lyarwood | stephenfin: and I'll likely ask for the same later in the cycle for the block layer | |
| 09:58:39 | stephenfin | fair :) | |
| 09:58:39 | stephenfin | fair :) | |
| 10:12:14 | gibi | stephenfin: I will check it after my lunch | |
| 10:12:14 | gibi | stephenfin: I will check it after my lunch | |
| 10:24:12 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788467 | |
| 10:24:47 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788468 | |
| 10:24:47 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788468 | |
| 10:26:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788469 | |
| 10:26:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788469 | |
| 10:41:04 | sean-k-mooney | stephenfin: +1 on the first patch for nova.pci | |
| 10:41:04 | sean-k-mooney | stephenfin: +1 on the first patch for nova.pci | |
| 10:41:15 | stephenfin | thanks :) | |
| 10:41:15 | stephenfin | thanks :) | |
| 10:41:28 | sean-k-mooney | stephenfin: i have 2 other review i want to complte first then ill see if i can get back to the rest | |
| 10:41:28 | sean-k-mooney | stephenfin: i have 2 other review i want to complte first then ill see if i can get back to the rest | |
| 10:45:02 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |
| 11:00:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Testing with sqlalchemy 1.4 https://review.opendev.org/c/openstack/nova/+/788471 | |
| 11:00:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Testing with sqlalchemy 1.4 https://review.opendev.org/c/openstack/nova/+/788471 | |
| 11:01:13 | gibi | fyi we are expected failures and therefore work here ^^ | |
| 11:01:13 | gibi | fyi we are expected failures and therefore work here ^^ | |
| 11:01:21 | gibi | s/expected/expecting/ | |
| 11:01:22 | gibi | s/expected/expecting/ | |
| 11:11:22 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 11:11:33 | gibi | reported https://bugs.launchpad.net/nova/+bug/1926426 to track the work | |
| 11:11:35 | openstack | Launchpad bug 1926426 in OpenStack Compute (nova) "Nova is not compatible with sqlalchemy 1.4" [High,Triaged] | |
| 11:11:35 | gibi | reported https://bugs.launchpad.net/nova/+bug/1926426 to track the work | |
| 11:11:35 | openstack | Launchpad bug 1926426 in OpenStack Compute (nova) "Nova is not compatible with sqlalchemy 1.4" [High,Triaged] | |
| 11:13:17 | sean-k-mooney | is the issue the test or the production code? | |
| 11:13:17 | sean-k-mooney | is the issue the test or the production code? | |
| 11:13:56 | sean-k-mooney | looks like maybe both | |
| 11:13:56 | sean-k-mooney | looks like maybe both | |
| 11:14:02 | sean-k-mooney | have we capped it in UC | |
| 11:14:02 | sean-k-mooney | have we capped it in UC | |
| 11:15:24 | sean-k-mooney | ah we had to 1.3.23 previously | |
| 11:15:24 | sean-k-mooney | ah we had to 1.3.23 previously | |
| 11:15:50 | gibi | it is a test coming from a proposed UC bump | |
| 11:15:50 | gibi | it is a test coming from a proposed UC bump | |
| 11:16:07 | gibi | so far we see one oslo.db issue but we also seem to have some nova specific failure modes as well | |
| 11:16:07 | gibi | so far we see one oslo.db issue but we also seem to have some nova specific failure modes as well | |
| 11:56:26 | gibi | sean-k-mooney: Did I understood the comment from the PTG well about when we need direction aware and when we need direction less pps resource? https://review.opendev.org/c/openstack/neutron-specs/+/785236/3/specs/xena/qos-minimum-guaranteed-packet-rate.rst#266 | |
| 11:56:26 | gibi | sean-k-mooney: Did I understood the comment from the PTG well about when we need direction aware and when we need direction less pps resource? https://review.opendev.org/c/openstack/neutron-specs/+/785236/3/specs/xena/qos-minimum-guaranteed-packet-rate.rst#266 | |
| 11:58:37 | sean-k-mooney | sorry have nto got to your spec yet today but ill take a look at that comment now one sec | |
| 11:58:37 | sean-k-mooney | sorry have nto got to your spec yet today but ill take a look at that comment now one sec | |
| 11:59:41 | sean-k-mooney | gibi: so ya | |
| 11:59:41 | sean-k-mooney | gibi: so ya | |
| 12:00:01 | sean-k-mooney | we can either put the sum of the direct based values in the request | |
| 12:00:01 | sean-k-mooney | we can either put the sum of the direct based values in the request | |
| 12:00:22 | sean-k-mooney | or we can have 3 resources class and just make the user choose the correct policy | |
| 12:00:22 | sean-k-mooney | or we can have 3 resources class and just make the user choose the correct policy | |
| 12:01:46 | sean-k-mooney | i kind of like having 3 reosuce classes PPS_TOTAL, PPS_INGRESS and PPS_EGRESS | |
| 12:01:47 | sean-k-mooney | i kind of like having 3 reosuce classes PPS_TOTAL, PPS_INGRESS and PPS_EGRESS | |
| 12:01:52 | gibi | so then in case of hw offloaded OVS the packet processing bottleneck is not some kind of shared resource (like the CPU in case of normal OVS) but some direction specific hardware resoruce? | |
| 12:01:52 | gibi | so then in case of hw offloaded OVS the packet processing bottleneck is not some kind of shared resource (like the CPU in case of normal OVS) but some direction specific hardware resoruce? | |
| 12:02:37 | gibi | hence we need to track resource inventory per direction separately | |
| 12:02:37 | gibi | hence we need to track resource inventory per direction separately | |
| 12:02:41 | sean-k-mooney | well yes and know. the pcie bandwith is a shared resouce but hardware offloaded ovs use sriov VFs for the dataplane | |
| 12:02:41 | sean-k-mooney | well yes and know. the pcie bandwith is a shared resouce but hardware offloaded ovs use sriov VFs for the dataplane | |
| 12:03:03 | sean-k-mooney | so we can pretend it just sriov in this case | |
| 12:03:03 | sean-k-mooney | so we can pretend it just sriov in this case | |
| 12:03:22 | sean-k-mooney | vdpa is more or less the same in that the parent of the vdpa device atleat today is a VF | |
| 12:03:23 | sean-k-mooney | vdpa is more or less the same in that the parent of the vdpa device atleat today is a VF | |
| 12:03:54 | gibi | so in this case the logic that is implemented in OVS runs on the specific hardware? | |
| 12:03:55 | gibi | so in this case the logic that is implemented in OVS runs on the specific hardware? | |
| 12:04:59 | gibi | anyhow I think I get it, the HW offload OVS is like the SRIOV VF case | |
| 12:04:59 | gibi | anyhow I think I get it, the HW offload OVS is like the SRIOV VF case | |
| 12:05:00 | sean-k-mooney | how it works is the ovs vswitchd process caluates openflow rules as normal and then use the tcflower protocal to install those flows into the hardware dataplane if it supprot them | |
| 12:05:01 | sean-k-mooney | how it works is the ovs vswitchd process caluates openflow rules as normal and then use the tcflower protocal to install those flows into the hardware dataplane if it supprot them | |
| 12:05:24 | gibi | sean-k-mooney: thanks that helps visualizing the situation for me | |
| 12:05:24 | gibi | sean-k-mooney: thanks that helps visualizing the situation for me | |
| 12:06:19 | sean-k-mooney | basically you can thinkg of the programming model like a cache if the hardware can cache the rule in its hardware swtich it will process them in hardware. the ovs proces just caculates them as normal and they are then copied to the hardware | |
| 12:06:19 | sean-k-mooney | basically you can thinkg of the programming model like a cache if the hardware can cache the rule in its hardware swtich it will process them in hardware. the ovs proces just caculates them as normal and they are then copied to the hardware | |
| 12:06:50 | sean-k-mooney | what that means in partcie is the first packet(s) of each connection is processed in software and then hardware takes over | |
| 12:06:50 | sean-k-mooney | what that means in partcie is the first packet(s) of each connection is processed in software and then hardware takes over | |
| 12:08:07 | gibi | I see | |
| 12:09:18 | gibi | and in this hardwer the incoming and outgoing packet processing is implemented independently so we can run out of one direction while the other direction still has capacity | |
| 12:09:18 | gibi | and in this hardwer the incoming and outgoing packet processing is implemented independently so we can run out of one direction while the other direction still has capacity | |
| 12:09:40 | gibi | and therefore we need separated resource tracking | |
| 12:09:40 | gibi | and therefore we need separated resource tracking | |
| 12:10:11 | sean-k-mooney | i think that depens on the nic but in principal yes the internal capasity of the switch is higher then the phsyical connectors | |
| 12:10:11 | sean-k-mooney | i think that depens on the nic but in principal yes the internal capasity of the switch is higher then the phsyical connectors | |