14:00:25 <lajoskatona> #startmeeting neutron_drivers 14:00:25 <opendevmeet> Meeting started Fri Mar 18 14:00:25 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:25 <opendevmeet> The meeting name has been set to 'neutron_drivers' 14:00:29 <lajoskatona> o/ 14:00:35 <mlavalle> o/ 14:00:46 <obondarev> hi 14:01:13 <yamamoto> hi 14:01:22 <noonedeadpunk> o/ 14:01:40 <amotoki> hi 14:02:20 <haleyb> hi 14:03:06 <lajoskatona> I think we can start 14:03:46 <lajoskatona> The first topic from the list regarding GARP are not sent during ha router master state transition we can postpone 14:04:00 <lajoskatona> So the first one fortoday: 14:04:04 <lajoskatona> [QoS][OvS] implement QoS bandwidth limitation by leveraging ovs meter (#link https://bugs.launchpad.net/neutron/+bug/1964342 ) 14:04:04 <noonedeadpunk> Are we? 14:04:11 <mlavalle> yeah, I think that's trident's topic 14:04:14 <noonedeadpunk> Because that's quite critical 14:04:20 <slaweq> o/ 14:04:36 <noonedeadpunk> Basic functionality is quite broken and this topic has not been taken for meeting for 3 weeks now 14:04:57 <lajoskatona> noonedeadpunk: I jsut asked trident if we can discuss it today, but they had no time for testing the possible solutions this week 14:05:16 <mlavalle> yeap 14:05:39 <slaweq> is it about ingress or egress traffic (from vm point of view)? 14:05:42 <slaweq> or both? 14:06:07 <trident> noonedeadpunk: Yeah, me and damiandabrowski[m] discussed a bit and there is more testing on our side that needs to be done before we really have anything new to report on it. 14:06:09 <noonedeadpunk> I'm not sure about egress 14:06:35 <noonedeadpunk> Ingress for sure is broken 14:07:19 <slaweq> https://review.opendev.org/c/openstack/neutron/+/832662 that should fix current implementation of the ingress bw limit in ml2/ovs 14:07:33 <noonedeadpunk> I'm not neutron code expert, but can try to help out. But eventuaalyy any solutions I saw has own flaws... 14:08:19 <lajoskatona> noonedeadpunk: could you sync with trident and than next week we can check the topic 14:08:34 <noonedeadpunk> I don't think it will as VIP is not functional and mentioned patch not touching that part? 14:08:37 <lajoskatona> noonedeadpunk: is that work for you? 14:08:44 <noonedeadpunk> lajoskatona: yes, thanks! 14:08:59 <lajoskatona> noonedeadpunk: cool 14:09:03 <mlavalle> so talking now about QoS? 14:09:18 <noonedeadpunk> sorry for interrupting:) I just joined to check out on the bug that was skipped without mentioning reason again :) 14:09:24 <lajoskatona> yes I think we can jump on it 14:09:57 <lajoskatona> noonedeadpunk: true, I forgot to mention that I asked about it trident 14:10:29 <lajoskatona> So the coming rfe: [QoS][OvS] implement QoS bandwidth limitation by leveraging ovs meter (#link https://bugs.launchpad.net/neutron/+bug/1964342 ) 14:10:37 <lajoskatona> this is from liuyulong 14:11:42 <lajoskatona> If I understand correctly it is to have another QoS Bandwidth limit driver with os-ken and and ovs meter rules 14:12:15 <slaweq> sorry, I though we are talking about this one all the time :) 14:12:22 <mlavalle> LOL 14:12:28 <mlavalle> yeah I figured 14:12:32 * slaweq is focused mostly on other meeting now 14:13:28 <slaweq> regarding this qos bw limit rfe - what's the point of having 2 different ways to configure it in ovs agent? I would just go with one which works better 14:13:44 <mlavalle> agree 14:13:55 <slaweq> so if using meters will be more accurate/efficient/better in other way - lets go with it and replace current implementation 14:14:11 <slaweq> if it's not better, what's the point of adding it to the code? 14:14:15 <lajoskatona> slaweq: valid point 14:14:20 <slaweq> that's my opinion at least 14:14:29 <mlavalle> I agree 14:14:48 <slaweq> but tbh I would like to see ralonsoh's thoughts on that one before approving/rejecting it 14:14:56 <mlavalle> it seems he is trying to justify this from the off loading perspective 14:15:01 <mlavalle> to smart-nic 14:15:16 <mlavalle> but then he states that tc can also be off-loaded 14:15:24 <mlavalle> I bit confusing 14:15:41 <lajoskatona> the current driver uses ovsdb 14:15:55 <lajoskatona> sorry half finished sentence.... 14:16:28 <lajoskatona> so that one was confusing for me also, as I don't see why offloading is better with the proposed solution 14:17:30 <obondarev> agree, need to clarify what are the benefits 14:18:57 <lajoskatona> ok, I add the questions to the bug, and ask liuyulong to present the asked details, is that ok? 14:19:11 <obondarev> +§ 14:19:15 <obondarev> +1 14:20:18 <mlavalle> perfect 14:20:20 <mlavalle> +1 14:20:20 <amotoki> +1 14:20:40 <lajoskatona> ok, thanks 14:20:54 <lajoskatona> Next topic is: 14:21:05 <lajoskatona> DHCP agent scheduler filtering ignored when agent service restarted (#link https://bugs.launchpad.net/neutron/+bug/1964765 ) 14:21:15 <lajoskatona> it's from BBC as I see 14:22:16 <amotoki> honestly I am not sure this is a bug or not.... 14:23:15 <lajoskatona> summary is to have possiblity to schedule network on a group of dhcp agents specified by some regex filtering or similar 14:23:23 <obondarev> I think it’s a fair expectation to have consistent filtering of dhcp agents when network (auto)scheduling 14:23:47 <lajoskatona> amotoki: your decision to mark it a srfe was really good, thanks 14:24:24 <lajoskatona> obondarev: true, I can imagine usecases to be useful like the one in the bug report 14:26:08 <obondarev> from the other hand changing this behaviour (skip filtering on net auto schedule) might break things for someone 14:27:27 <obondarev> for this I think a new parameter in the Filter itself might be added - whether filter should be applied on net auto-schedule (agent restart) 14:27:35 <amotoki> is it the right thing to skip filtering? I think it is better to apply consistent filtering if there is some inconsistency. 14:28:06 <obondarev> this will let us avoid new config option 14:29:16 <lajoskatona> and what about a new scheduler and if somebody needs this with possible traps, they select it in config? 14:29:59 <obondarev> new scheduler or new filter? 14:30:55 <lajoskatona> I thought new scheduler, as that is configurable 14:31:15 <amotoki> I think two topics are mixed. the one is about a new filtering/scheduler and the other point is that filtering is skipped when agent restart. 14:31:39 <amotoki> i am not sure the second point only affects the new filtering mentioned in the bug. 14:34:29 <obondarev> afaiu only segment related filtering is currently done on agent restart 14:34:49 <obondarev> all others are skipped, both old and new ones 14:35:55 <lajoskatona> ok so the LP can be split to an RFE and an actual bug? 14:37:39 <obondarev> I think the bug is just to decide if we should enable filters on agent restart 14:38:19 <amotoki> obondarev: agree 14:38:26 <obondarev> and my point is - let's enable filtering on agent restart for those filters that explicitly say "apply me on restart" - then we can decide if existing filters should add this flag or not 14:39:57 <lajoskatona> +1 14:40:03 <amotoki> +1 14:40:15 <amotoki> it looks like that the bug author does not request to add a new filter in neutron. the author just uses their new filter as an example to explain what happens. 14:40:37 <amotoki> so I totally agree with obondarev's point 14:41:26 <lajoskatona> amotoki: possible, I concerned more on the filter they created 14:42:50 <obondarev> not sure this new filter is even going to be upstreamed 14:43:12 <obondarev> I mean if author has such plans 14:43:45 <lajoskatona> ok, than the summary of this LP is: allow new flag for filters to execute them on agent restart, and set this to False for already existing filters 14:44:05 <lajoskatona> obondarev: possible 14:44:26 <obondarev> or to accept it as False if filter doesn't have this parameter 14:44:45 <fnordahl> lajoskatona: (re question about smartnic_dpu docs, screnshot and possible marketing page reference) apologies for the tardy response, that is an excellent idea. Are you asking for expansion of the existing doc page or some oob screenshot of stuff in action? 14:45:32 <lajoskatona> obondarev: +1 14:46:01 <lajoskatona> fnordahl: just a sec we are at the end of the meeting 14:46:38 <lajoskatona> ok regarding DHCP scheduling/filtering: is it ok this way for everybody? 14:46:49 <obondarev> +1 14:47:35 <amotoki> I am still unclear a bit. I think AZ schduler does the similar thing so it might be affected, while network AZ and network segments are used together. 14:48:40 <amotoki> s/are not used together/ 14:51:11 <obondarev> so do you suggest to enable it for all filters on agent restart? 14:51:52 <amotoki> what is "this way"? is it to accept filtering in dhcp RPC as False? 14:52:31 <amotoki> if so, I am okay with it. 14:52:38 <amotoki> If the current behavior affects the existing scheduler, we can fix it separately. 14:53:08 <lajoskatona> amotoki: for this way I meant this : "allow new flag for filters to execute them on agent restart, and set this to False for already existing filters" 14:53:27 <obondarev> IOW nothing changes for current filters, new filters can specify if they should filter on agent restart 14:53:47 <lajoskatona> yes that's my understanding also 14:53:49 <amotoki> lajoskatona: obondarev: thanks for the clarification. I got it. 14:54:47 <lajoskatona> amotoki: :-) this is a tricky LP bug, but really good discussion 14:55:12 <lajoskatona> ok, could you vote on in please if it is ok for you? 14:55:21 <mlavalle> +1 14:55:28 <amotoki> +1 14:55:31 <lajoskatona> +1 14:55:32 <obondarev> +1 14:55:52 <yamamoto> +1 14:56:12 <lajoskatona> ok, thanks 14:56:28 <lajoskatona> if there is nothing more to discuss, we can close the meeting 14:57:29 <lajoskatona> #endmeeting