| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-28 | |||
| 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 | |
| 12:10:45 | sean-k-mooney | so it can run out of capasity to transmit to the datacenter network before its ablity to swtich between vms on the same host | |
| 12:10:45 | sean-k-mooney | so it can run out of capasity to transmit to the datacenter network before its ablity to swtich between vms on the same host | |
| 12:11:17 | sean-k-mooney | although intel tend and mellonox until recently had a habbit of oversubscibing ther port bandwith | |
| 12:11:17 | sean-k-mooney | although intel tend and mellonox until recently had a habbit of oversubscibing ther port bandwith | |
| 12:11:59 | sean-k-mooney | i.e. intel 2*40G fortviles only had 56Gb/s of pcie bandwith | |
| 12:12:00 | sean-k-mooney | i.e. intel 2*40G fortviles only had 56Gb/s of pcie bandwith | |
| 12:12:53 | sean-k-mooney | which is fine for the 2*25G card but ya pcie bandwith and phycial port bandwith can often be less the the chip bandwith in the data center space | |
| 12:12:53 | sean-k-mooney | which is fine for the 2*25G card but ya pcie bandwith and phycial port bandwith can often be less the the chip bandwith in the data center space | |
| 12:13:40 | sean-k-mooney | the assumtion often is that you are using 2 port cards for HA not more bandwitr/pps | |
| 12:13:40 | sean-k-mooney | the assumtion often is that you are using 2 port cards for HA not more bandwitr/pps | |
| 12:14:16 | gibi | when you say "run out of capasity to transmit to the datacenter" do you mean it runs out of physical nework bandwidth? | |
| 12:14:16 | gibi | when you say "run out of capasity to transmit to the datacenter" do you mean it runs out of physical nework bandwidth? | |
| 12:14:29 | sean-k-mooney | yep | |
| 12:14:43 | gibi | so while it can still swtich packets, it cannot transmit them | |
| 12:14:43 | gibi | so while it can still swtich packets, it cannot transmit them | |
| 12:15:09 | gibi | but then this is showing just that the packet processing capacity is independent from the bandwidth | |
| 12:15:09 | gibi | but then this is showing just that the packet processing capacity is independent from the bandwidth | |
| 12:15:43 | gibi | it does not show that switching incoming packets are independend from switching outgoing packets | |
| 12:15:43 | gibi | it does not show that switching incoming packets are independend from switching outgoing packets | |
| 12:15:47 | sean-k-mooney | ya the 2*25G intel fortvales actully had 2 40G chips one per uplink port but had 25G phys | |
| 12:15:47 | sean-k-mooney | ya the 2*25G intel fortvales actully had 2 40G chips one per uplink port but had 25G phys | |
| 12:17:27 | sean-k-mooney | gibi: you are right it does not show they are independeint on the recive side if you have an intel cpu with vt-c | |
| 12:17:27 | sean-k-mooney | gibi: you are right it does not show they are independeint on the recive side if you have an intel cpu with vt-c | |
| 12:17:56 | sean-k-mooney | that allows supported nic to place recived packet directly into the cpus l3 cache | |
| 12:17:56 | sean-k-mooney | that allows supported nic to place recived packet directly into the cpus l3 cache | |
| 12:18:40 | sean-k-mooney | on transmit i know the cpu can do a dma transfre to the nic queue or indead to a zerocopy transmit in some cases | |
| 12:18:40 | sean-k-mooney | on transmit i know the cpu can do a dma transfre to the nic queue or indead to a zerocopy transmit in some cases | |
| 12:20:36 | gibi | OK, I rest my case. I will do allow the admin to configure either two direction aware pps resource inventory (in case of offloaded OVS) or a single direction less resource inventory (for the normal OVS) | |
| 12:20:36 | gibi | OK, I rest my case. I will do allow the admin to configure either two direction aware pps resource inventory (in case of offloaded OVS) or a single direction less resource inventory (for the normal OVS) | |
| 12:20:53 | sean-k-mooney | well no | |
| 12:20:53 | sean-k-mooney | well no | |
| 12:21:16 | sean-k-mooney | if you think that scoping this down to just normal ovs for now is the best way forward that would be ok | |
| 12:21:16 | sean-k-mooney | if you think that scoping this down to just normal ovs for now is the best way forward that would be ok | |
| 12:21:58 | sean-k-mooney | it would proably be nice to support both modesl as you said but we could start with the one you want | |
| 12:21:58 | sean-k-mooney | it would proably be nice to support both modesl as you said but we could start with the one you want | |
| 12:22:18 | gibi | I can do both, this is not the hard part (I guess :D)_ | |
| 12:22:18 | gibi | I can do both, this is not the hard part (I guess :D)_ | |
| 12:22:21 | sean-k-mooney | i just would not like to see logic to traslate driction based request into driectionless | |