| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-28 | |||
| 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 | |
| 12:22:21 | sean-k-mooney | i just would not like to see logic to traslate driction based request into driectionless | |
| 12:23:00 | sean-k-mooney | the translation is the bit i found slightly unclean about the proposal | |
| 12:23:00 | sean-k-mooney | the translation is the bit i found slightly unclean about the proposal | |
| 12:24:06 | gibi | the QoS rule will be direction aware. So that is good. | |
| 12:24:06 | gibi | Then in case of normal OVS should we still allow configuring direction aware resource inventory? | |
| 12:24:06 | gibi | the QoS rule will be direction aware. So that is good. | |
| 12:24:06 | gibi | Then in case of normal OVS should we still allow configuring direction aware resource inventory? | |
| 12:24:23 | gibi | that seems wrong to me as both direction are handled by the same set of CPUs runnig the OVS software | |
| 12:24:23 | gibi | that seems wrong to me as both direction are handled by the same set of CPUs runnig the OVS software | |
| 12:24:35 | sean-k-mooney | well i kind of thik we shoudl have 3 polices as i said above | |
| 12:24:35 | sean-k-mooney | well i kind of thik we shoudl have 3 polices as i said above | |
| 12:24:54 | gibi | ohh | |
| 12:24:54 | gibi | ohh | |
| 12:24:55 | sean-k-mooney | 2 that are direction aware and 1 that is drectionless | |
| 12:24:55 | sean-k-mooney | 2 that are direction aware and 1 that is drectionless | |
| 12:25:19 | sean-k-mooney | that map directly to the PPS_TOTAL, PPS_INGRESS and PPS_EGRESS resouce classes | |
| 12:25:19 | sean-k-mooney | that map directly to the PPS_TOTAL, PPS_INGRESS and PPS_EGRESS resouce classes | |
| 12:25:20 | gibi | so for vnic_type=normal the user should only use a directionless QoS policy | |
| 12:25:20 | gibi | so for vnic_type=normal the user should only use a directionless QoS policy | |
| 12:25:24 | sean-k-mooney | yep | |
| 12:25:49 | gibi | OK now I got your point | |
| 12:25:49 | gibi | OK now I got your point | |
| 12:26:19 | gibi | 3 resource classes and 3 QoS rule types | |
| 12:26:19 | gibi | 3 resource classes and 3 QoS rule types | |
| 12:26:25 | sean-k-mooney | so ovs would report PPS_TOTAL inventories and the directionless pps rule would consume it | |
| 12:26:26 | sean-k-mooney | so ovs would report PPS_TOTAL inventories and the directionless pps rule would consume it | |
| 12:26:32 | sean-k-mooney | yep | |
| 12:26:44 | sean-k-mooney | and no need for special logic to translate between them | |
| 12:26:44 | sean-k-mooney | and no need for special logic to translate between them | |
| 12:27:25 | gibi | OK so it is a bit more complexity to the user to select the proper QoS rule but in return we never lie about in the QoS policy about the direction awareness | |
| 12:27:25 | gibi | OK so it is a bit more complexity to the user to select the proper QoS rule but in return we never lie about in the QoS policy about the direction awareness | |
| 12:27:30 | sean-k-mooney | sorry i tought i had said that at the PTG but maybe i was not very clear | |
| 12:27:30 | sean-k-mooney | sorry i tought i had said that at the PTG but maybe i was not very clear | |
| 12:27:58 | gibi | sean-k-mooney: no it is my bad, I mixied the QoS policy part with the resource classes | |
| 12:27:58 | gibi | sean-k-mooney: no it is my bad, I mixied the QoS policy part with the resource classes | |
| 12:28:16 | gibi | next step | |
| 12:28:16 | gibi | next step | |
| 12:28:27 | sean-k-mooney | but ya its a little more complet for the tenant but simpler in code | |
| 12:28:27 | sean-k-mooney | but ya its a little more complet for the tenant but simpler in code | |
| 12:28:32 | sean-k-mooney | at least i think it is | |
| 12:28:32 | sean-k-mooney | at least i think it is | |
| 12:28:38 | gibi | yepp | |
| 12:29:54 | gibi | so next step, when we have the directionless QoS policy and later we want to implement data plane enforcement for that, then how we map the direction less min guarantee to direction aware pps rate limit rules to do enforcement? | |
| 12:29:54 | gibi | so next step, when we have the directionless QoS policy and later we want to implement data plane enforcement for that, then how we map the direction less min guarantee to direction aware pps rate limit rules to do enforcement? | |
| 12:31:06 | gibi | this is the packet rate limiter work https://bugs.launchpad.net/neutron/+bug/1912460 from Liu | |
| 12:31:09 | openstack | Launchpad bug 1912460 in neutron "[RFE] [QoS] add qos rule type packet per second (pps)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) | |
| 12:31:09 | gibi | this is the packet rate limiter work https://bugs.launchpad.net/neutron/+bug/1912460 from Liu | |
| 12:31:09 | openstack | Launchpad bug 1912460 in neutron "[RFE] [QoS] add qos rule type packet per second (pps)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) | |
| 12:31:42 | gibi | and as I understood from ralonso the basic solution for the guarante is to set up max limits := min guarante for all the traffic | |
| 12:31:42 | gibi | and as I understood from ralonso the basic solution for the guarante is to set up max limits := min guarante for all the traffic | |
| 12:31:51 | sean-k-mooney | that is a goog question we have 3 choices i guess, 1 dont, 2 split it evenly between each direction(assuming its a share resouces), 3 assume they are indepented so allwo it for both | |
| 12:31:51 | sean-k-mooney | that is a goog question we have 3 choices i guess, 1 dont, 2 split it evenly between each direction(assuming its a share resouces), 3 assume they are indepented so allwo it for both | |
| 12:33:19 | sean-k-mooney | gibi: ya so like badnwith, the mins for ovs are not enfroced by ovs so you would use max ppp instead to do enfrocement | |
| 12:33:20 | sean-k-mooney | gibi: ya so like badnwith, the mins for ovs are not enfroced by ovs so you would use max ppp instead to do enfrocement | |
| 12:33:44 | sean-k-mooney | for any backend that can enforce it then min should be enough | |
| 12:33:44 | sean-k-mooney | for any backend that can enforce it then min should be enough | |
| 12:33:57 | sean-k-mooney | and you should not need max rules | |
| 12:33:57 | sean-k-mooney | and you should not need max rules | |
| 12:34:09 | gibi | OK so in case of normal OVS where we have the directionless QoS we know that it is not an independent resource and therefore we would need to split it but splitting it equally might not what the user intended originally | |
| 12:34:09 | gibi | OK so in case of normal OVS where we have the directionless QoS we know that it is not an independent resource and therefore we would need to split it but splitting it equally might not what the user intended originally | |
| 12:35:28 | sean-k-mooney | gibi: well since the enforcement will be doen by the max policy the could use a directionless min policy with ad directionful? pair of max policies | |
| 12:35:28 | sean-k-mooney | gibi: well since the enforcement will be doen by the max policy the could use a directionless min policy with ad directionful? pair of max policies | |
| 12:36:08 | sean-k-mooney | so min_totall_pps=1000 max_ingress_pps=200 max_egress_pps=800 | |
| 12:36:08 | sean-k-mooney | so min_totall_pps=1000 max_ingress_pps=200 max_egress_pps=800 | |
| 12:36:22 | gibi | so we are sure that OVS will never have the capability to enforce min alone? so we alway need to manually define both min and max | |
| 12:36:22 | gibi | so we are sure that OVS will never have the capability to enforce min alone? so we alway need to manually define both min and max | |
| 12:37:19 | sean-k-mooney | well intel wehere trying to get this into ovs-dpdk for a few year but could never get around the fact they would basically have to dedicate 1 core to doing the min enforcement | |