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