15:00:38 <ralonsoh> #startmeeting neutron_qos 15:00:39 <openstack> Meeting started Tue Mar 24 15:00:38 2020 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:42 <openstack> The meeting name has been set to 'neutron_qos' 15:00:42 <ralonsoh> hello 15:00:45 <slaweq> hi :) 15:01:03 <ralonsoh> yeah, the ofctl removal is not easy 15:01:09 <ralonsoh> there is no 1:1 conversion 15:01:18 <ralonsoh> let's wait 30 secs 15:02:02 <ralonsoh> #topic RFEs 15:02:11 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1858610 15:02:12 <openstack> Launchpad bug 1858610 in neutron "[RFE] Qos policy not supporting sharing bandwidth between several nics of the same vm." [Undecided,New] 15:02:27 <ralonsoh> we are still waiting for a spec or a POC 15:02:41 <slaweq> and that seems to be pretty complex 15:02:47 <ralonsoh> I'll ping the author of the RFE today just to know the status 15:02:51 <ralonsoh> yeah, it is 15:03:25 <ralonsoh> so let's wait for it but I don't know if we'll see something landed this cycle 15:03:45 <ralonsoh> and that's all for today in this section! 15:04:16 <slaweq> I don't think it will be this cycle 15:04:23 <ralonsoh> I dropped the classifier RFE because there are no volunteers to continue with the work 15:04:46 <ralonsoh> so I encourage anyone to continue with it 15:05:04 <ralonsoh> reference: 15:05:06 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527 15:05:09 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard) 15:05:35 <ralonsoh> is something missing here? 15:05:58 <ralonsoh> #topic Bugs 15:06:03 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1864630 15:06:05 <openstack> Launchpad bug 1864630 in neutron "Hard Reboot VM with multiple port lost QoS " [Undecided,Fix released] - Assigned to Nguyen Thanh Cong (congnt95) 15:06:16 <ralonsoh> well addressed by https://review.opendev.org/#/c/709687/ 15:06:19 <ralonsoh> already merged 15:06:24 <slaweq> ++ 15:06:36 <ralonsoh> and there is a backport https://review.opendev.org/#/q/If8edd29dd741f1688ffcac341fd58173539ba000 15:06:51 <ralonsoh> but this patch in Train should be rebased on top of 15:06:56 <ralonsoh> (one sec) 15:07:04 <ralonsoh> https://review.opendev.org/#/c/714417/ 15:07:26 <ralonsoh> (now in Train we have a small issue with rally) 15:07:33 <ralonsoh> so we need to wait for it 15:07:37 <slaweq> not so small :) 15:07:39 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1868691 15:07:41 <openstack> Launchpad bug 1868691 in neutron "neutron-rally-task fails 100% on stable branches" [Critical,In progress] - Assigned to Bernard Cafarelli (bcafarel) 15:07:45 <ralonsoh> I know, I know... 15:07:46 <slaweq> but bcafarel is on it already 15:07:52 <ralonsoh> bcafarel++ 15:08:25 <ralonsoh> so the OVS QoS bug is almost solved, even in T 15:08:33 <ralonsoh> next one 15:08:35 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1863852 15:08:36 <openstack> Launchpad bug 1863852 in neutron "[OVN]Could not support more than one qos rule in one policy" [Medium,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 15:08:49 <slaweq> ralonsoh: should this be backported also to Stein and older? 15:08:55 <slaweq> or it applies only to Train? 15:08:57 <ralonsoh> hmmmmm 15:09:03 <ralonsoh> let me check that 15:09:14 <ralonsoh> I'll check that after this meeting 15:09:32 <slaweq> no, I can check it on my own later, I just though that maybe You will know :) 15:09:34 <slaweq> thx 15:09:38 <ralonsoh> no, sorry 15:10:14 <ralonsoh> that bug was open to master and I know this is also happening in T 15:10:22 <ralonsoh> but I don't know in previous versions 15:10:26 <slaweq> ok 15:10:37 <ralonsoh> ok, the OVN QoS bug 15:10:48 <ralonsoh> maciejjozefczyk found today some issues in the patch 15:11:01 <ralonsoh> #link https://review.opendev.org/#/c/711317/ 15:11:09 <ralonsoh> and I still need to reply to haleyb 15:11:25 <maciejjozefczyk> ralonsoh, slaweq this should be cherry-picked to train (qos) 15:11:31 <ralonsoh> but is almost ready, probably in the next PS 15:11:46 <ralonsoh> yes, this QoS refactor should be backported to networking-ovn 15:11:57 <ralonsoh> (this is going to be funny...) 15:11:57 <maciejjozefczyk> actually everything related to qos should be in train, cause in train we have a limited qos functionality, and mainly its broken 15:12:23 <ralonsoh> yeah, once this patch is merged, I'll push a patch for n-ovn in T 15:13:04 <maciejjozefczyk> ralonsoh, thanks! 15:13:09 <ralonsoh> yw 15:13:31 <ralonsoh> and so far, this is everything I have for today in the meeting backlog! 15:13:43 <ralonsoh> do you have any other bug? 15:13:50 <slaweq> nope 15:14:23 <ralonsoh> ok, so next section 15:14:27 <ralonsoh> #topic Open Discussion 15:14:39 <ralonsoh> something to add? 15:14:46 <slaweq> not from me 15:14:49 <ralonsoh> or do you want 45 mins back? 15:14:50 <ralonsoh> heheeh 15:15:06 <maciejjozefczyk> Yes, I want to add one thing 15:15:15 <ralonsoh> please 15:15:38 <maciejjozefczyk> We have bug in Core OVN related to qos, described here 15:15:40 <maciejjozefczyk> #link https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049866.html 15:15:45 <ralonsoh> yeah... 15:15:59 <maciejjozefczyk> Actually if there are for example 2 ports from the same network on the same chassis (same compute) 15:16:07 <maciejjozefczyk> those 2 ports share one 'qos bucket' 15:16:17 <maciejjozefczyk> that means the limit is shared between those ports 15:16:53 <maciejjozefczyk> so if one port is noisy - the other port from the same network could have a problem 15:17:20 <ralonsoh> or just transmitting one flow 15:17:22 <maciejjozefczyk> The solution would be to create a meter per each OVS inport, and I'm discussing it with OVN folks, to address that 15:17:26 <ralonsoh> the BW will be shared 15:17:42 <ralonsoh> but why per inport? 15:17:49 * slaweq needs to leave for few minutes, sorry 15:17:52 <ralonsoh> why not one meter per OVN QoS rule? 15:17:53 <maciejjozefczyk> sorry, inport or outport 15:17:58 <ralonsoh> slaweq, bye 15:18:28 <maciejjozefczyk> slaweq, bb! 15:18:31 <ralonsoh> in a future, we'll have "match" fields with other than inport/outport 15:18:38 <ralonsoh> for example, filtering by ip or mac 15:18:41 <maciejjozefczyk> ralonsoh, ah yes 15:18:49 <ralonsoh> (for FIP, for example) 15:19:02 <maciejjozefczyk> ralonsoh, yes you're right 15:19:13 <ralonsoh> the point is, this is not like classfull HTC in TC 15:19:26 <ralonsoh> where you have a qdisc and classes and filters 15:19:37 <ralonsoh> everything organized in a tree 15:19:53 <ralonsoh> there is no dependency between ovn qos rules 15:20:05 <ralonsoh> so, IMO, there should be a meter per rule 15:20:15 <ralonsoh> another topic could be the performance... 15:20:35 <ralonsoh> but image you have 100 ports in one chassis 15:20:40 <ralonsoh> each one shaped 15:20:47 <ralonsoh> and 100 FIPs 15:20:58 <ralonsoh> so you'll need those 200 meters, each one different 15:21:22 <maciejjozefczyk> yes 15:22:30 <ralonsoh> what I don';t understand is the current OVN qos implementation 15:22:41 <ralonsoh> maybe there is a reason for that 15:22:51 <ralonsoh> and we need to implement the qos in another way 15:22:58 <ralonsoh> neutron qos for ovn 15:23:58 <ralonsoh> ok, something else to add? 15:24:06 <maciejjozefczyk> from me nope 15:24:18 <ralonsoh> thank you all and see you online! 15:24:24 <ralonsoh> #endmeeting