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