14:00:18 <slaweq> #startmeeting neutron_drivers
14:00:18 <opendevmeet> Meeting started Fri Jun 18 14:00:18 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:22 <slaweq> hi
14:00:24 <fnordahl> o/
14:00:25 <mlavalle> o/
14:00:35 <obondarev> hi
14:00:46 <amotoki> o/
14:00:48 <lajoskatona> i
14:00:49 <lajoskatona> Hi
14:01:09 <velizarx_> o/
14:01:16 <ralonsoh> hi
14:01:21 <yangyi01> hi
14:02:25 <dmitriis> o/
14:02:52 <slaweq> I think we can start
14:02:58 <slaweq> #topic RFEs
14:03:07 <slaweq> we have one new RFE for today
14:03:14 <slaweq> https://bugs.launchpad.net/neutron/+bug/1931953
14:03:42 <slaweq> which in fact isn't very new as we had something similar in the past
14:03:50 <slaweq> https://bugs.launchpad.net/neutron/+bug/1705536, https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr
14:04:05 <ralonsoh> I added this topic but I shouldn't talk about it
14:04:21 <slaweq> ralonsoh I think You should :)
14:04:44 <yangyi01> I filed this REF
14:04:47 <ralonsoh> yangyi01, will present this feature better than me
14:04:50 <ralonsoh> right
14:04:59 <slaweq> hi yangyi01, good that You are here :)
14:05:20 <yangyi01> ok, let me talk about why we need it.
14:06:05 <yangyi01> Actually, I have worke on this tough issue last year in OVS project.
14:06:31 <yangyi01> We want to use OVS DPDK in openstack
14:07:03 <mlavalle> who's we?
14:07:04 <yangyi01> But obviously it is very very bad as far as performance is concerned.
14:07:30 <yangyi01> Inpur, China-based cloud provider.
14:07:51 <mlavalle> ack
14:08:01 <yangyi01> I have fixed many perofermance issues on OVS DPDK side.
14:08:46 <yangyi01> including VXLAN TSO, GRO, GSO, UFO, etc.
14:09:43 <yangyi01> I also have a batch process patch to improve tap and veth performnce in OVS, it has been merged.
14:10:16 <yangyi01> that can improve performance significantly, but it is far not enough.
14:10:59 <yangyi01> it is best way not to use tap and veth in OVS DPDK case.
14:11:13 <yangyi01> that is why I want to have this REF.
14:12:10 <yangyi01> this can improve across-node L3 vm to vm performance and FIP performance dramatically.
14:12:25 <yangyi01> the result is really incredible.
14:13:02 <yangyi01> this REF also can improve OVS kernel performance and big UDP issue.
14:13:15 <mlavalle> in your RFE you mention that it is different to https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr. How is it different?
14:14:09 <yangyi01> now, big UDP or big ICMP  can't work in OVS kernel case with security group in linux bridge.
14:14:37 <yangyi01> yes, implementation way is different.
14:14:44 <mlavalle> how?
14:15:32 <yangyi01> I think old spec only considered virtual IP, didn't consider FIP.
14:15:57 <ralonsoh> it was, in centralized mode
14:16:19 <yangyi01> for FIP, only neutron as a SDN controller and handle ARP request can fix it.
14:17:32 <amotoki> IIRC current DVR supports FIP from compute nodes.
14:18:10 <yangyi01> yes, for SNAT, it also used FIP, that can be centralized or distributed.
14:18:14 <ralonsoh> for sure, L3 agents supports this, not the Intel implementation for OF DVR
14:18:48 <ralonsoh> but let's focus on the new implementation
14:19:09 <yangyi01> Intel just impelmented l3 agent by using openflow.
14:19:24 <yangyi01> I was Intel guy before.
14:19:48 <slaweq> do You think that Your solution may replace current DVR implementation, or we should keep both in-tree?
14:20:26 <yangyi01> if you chech that submited implementation patch, I don't think it can work, it din't install flow per FIP or qrouter.
14:21:06 <mlavalle> meaning it cannot replace the current DVR implementation?
14:21:52 <opendevreview> Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting  https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808
14:22:00 <yangyi01> We added a config option dvr_use_openflow, if set to True, l3 agent will install openflow to br-int, if false, old way can still work.
14:22:23 <yangyi01> my REF depends on current DVR impelmetation.
14:22:57 <amotoki> do you mean the neutron tree maintains two different OVS based DVR implementations?
14:23:04 <mlavalle> thanks for the clarification
14:23:54 <obondarev> I'd say not only DVR but all L3 agent, right?
14:24:04 <slaweq> so in Your implementation L3 agent will change flows in the br-int directly, right?
14:24:31 <yangyi01> I think it is ok. With old implementation there, users can use old namespaces to do anything as before.
14:25:03 <yangyi01> yes
14:25:10 <slaweq> my main concern is maintenance of that code, we will need to add new CI job to have it tested, etc.
14:25:12 <slaweq> :/
14:25:54 <yangyi01> it is worthy for super high performance.
14:26:24 <obondarev> an option is to have it in a separate networking-ovs-dvr repo, right?
14:26:36 <ralonsoh> that's a good option
14:26:51 <yangyi01> FIP can reach line speed, I don't think current implementation can attain this.
14:27:03 <ralonsoh> I have the same concern as slaweq. This is not like the distributed DHCP feature in OVS, that removes the need of any DHCP agent.
14:27:08 <mlavalle> or why don't we go in the opposite direction... could this proposal be used as a springboard to have a brand new DVR implementaion in tree?
14:27:09 <slaweq> or include it in networking-ovs-dpdk repo maybe?
14:27:26 <ralonsoh> here you are duplicating paths: with iptables or OF, but keeping the L3 agent
14:27:44 <ralonsoh> (and the L3 agent code is not easy to maintain)
14:28:17 <ralonsoh> networking-ovs-dpdk is dead
14:28:17 <mlavalle> that's why I say, take this as an opportunity for a new reset
14:28:26 <yangyi01> this isn't ML2 driver, main neutron tree is best place for this.
14:29:43 <mlavalle> yangyi01: what would it take to expand your effort to completely replace our current DVR implementation?
14:31:14 <yangyi01> Not sure, if it has been stable enough, we can remove old unnecesary DVR code.
14:31:20 <amotoki> our concern is mainly for the maintenance cost of having competing DVR implementations. It includes the number of CI jobs, review bandwitdh and deeper knowledge of specific impls.
14:31:35 * mlavalle understands slaweq and ralonsoh concerns about CI and all that. But meaybe this is an opportunity to offer our OVS deployments a more performant DVR implementation. THos OVS deployments will be around for a loong time
14:31:54 <ralonsoh> mlavalle, we should support linux bridge
14:32:07 <ralonsoh> that won't work with an OF based L3 agent
14:32:17 <slaweq> ralonsoh DVR don't works with linux bridge currently
14:32:21 <slaweq> so that's not an issue IMO
14:32:24 <ralonsoh> right
14:32:25 <ralonsoh> sorry
14:33:46 <mlavalle> all I'm saying is that we have and will have  for a long time OVS users and we should strive to improve their performance experience when the oppotunity arises. Maybe this is one of these opportunities if we expand the effort
14:33:47 <slaweq> TBH personally I'm a bit torn here - from one side I have this maintenance concern, but from the other hand I like idea of more performant DVR implementation, especially that old RFE for that was actually approved already long time ago :)
14:33:49 <ralonsoh> I'm ok with this if that means replace any other implementation. I prefer not to have two paths in the code
14:34:28 <mlavalle> yeah, I agree with not having two paths in the code
14:35:41 <yangyi01> Finally, we can have one path if new path is good enough, I'm not sure if it covers some corner cases.
14:36:17 <ralonsoh> you have my +1 if that RFE includes the replacement of all iptables/conntrack code and provides the same functionality
14:36:39 <ralonsoh> and a good spec to know how are you going to implement it
14:36:39 <mlavalle> so going back to yangyi01, could we re-scope your RFE / spec in such a way that the effort's goal is to replace our DVR implementation in OF?
14:36:54 <slaweq> I agree with ralonsoh - if that can finally be replacement for old implementation of DVR, than I'm ok with it
14:37:07 <slaweq> but IMO we will need much more detailed spec first
14:37:26 <amotoki> ralonsoh: what do you mean by "the replacement of all iptables/conntrack code"? is it the one related to the current DVR?
14:37:43 <amotoki> or l3-agent itself?
14:37:44 <ralonsoh> amotoki, yes, just this code
14:37:49 <yangyi01> No problem, please point out what parts it ddin't cover, I can add them.
14:37:53 <ralonsoh> no no, not all L3 agent, only DVR stuff
14:37:55 <mlavalle> ralonsoh: DVR, right?
14:38:00 <ralonsoh> yes
14:38:04 <amotoki> ralonsoh: thanks
14:38:04 <mlavalle> +1
14:38:29 <obondarev> what is L3 agent without DVR?
14:38:31 <yangyi01> I have iplemented it, maybe patch is best spec.
14:38:48 <ralonsoh> sorry no
14:38:51 <obondarev> in a DVR env DVR and L3 agent seem the same
14:38:54 <ralonsoh> I could help, but no
14:38:56 <yangyi01> I can submit my patch if you want to know details.
14:39:46 <yangyi01> l2 agent also handled many DVR-related stuff, DVR is very complicated.
14:39:48 <slaweq> yangyi01 only implementation will for sure not be enough, even if not detailed spec, we would need some docs patch at least with detailed description of tables/flows/etc.
14:40:18 <mlavalle> yeah, because we have to live with the maintenace issue
14:40:38 <mlavalle> so I'd say, let's start with a good spec of what is going to be done
14:40:54 <yangyi01> understood, developers prefer  code to docuemnt.
14:41:31 <mlavalle> yangyi01: we are being supportive of you, don't dismiss us as non-developers
14:41:45 <mlavalle> not very nice of you
14:43:13 <slaweq> so let's vote - I'm +1 to approve this rfe, but it's final goal should be to replace current dvr implementation, and we will need detailed spec and docs with description of how it works
14:43:22 <yangyi01> mlavalle, sorry, I can add parts you expect, please add your comments in current spec. not sure what parts are missed.
14:43:57 <ralonsoh> +1 with those conditions
14:44:11 <mlavalle> +1 with aformentioned conditions
14:44:22 <yangyi01> +1 by myself :-)
14:45:41 <slaweq> amotoki any thoughts?
14:45:47 <amotoki> +1. I agree the final goal should cover replacing with the current dvr impl. I think we need to cover the rough plan in the spec.
14:46:29 <slaweq> thx, I will mark rfe as approved with those mentioned conditions
14:46:48 <slaweq> and we can then review spec and then implementation as well
14:46:49 <mlavalle> include those conditions in your approval comment
14:46:58 <slaweq> mlavalle sure, I will
14:47:12 <slaweq> thx yangyi01 for the proposal
14:47:18 <slaweq> ok, that was the only rfe for today
14:47:24 <fnordahl> Anything you need answered to triage https://bugs.launchpad.net/neutron/+bug/1932154 for next weeks meeting?
14:47:31 <slaweq> do You have any other topics You would like to talk about?
14:47:46 <amotoki> yangyi01: one question: you said "add your comments in current spec". did you already propose some spec?
14:48:00 <yangyi01> One question, how long can a approved spec take to finish? This is a big engineering effort.
14:48:24 <yangyi01> yes, I have submited spec.
14:48:32 <slaweq> amotoki https://review.opendev.org/c/openstack/neutron-specs/+/796746
14:48:38 <slaweq> this is the spec
14:48:40 <amotoki> thanks. I just found it :)
14:49:10 <velizarx> could we discuss RFE from previous meeting https://bugs.launchpad.net/neutron/+bug/1931100?
14:49:26 <yangyi01> https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr-l3
14:49:37 <slaweq> fnordahl I asked ralonsoh to check Your rfe, I think he didn't check it yet
14:49:52 <ralonsoh> slaweq, I couldn't yet
14:50:04 <slaweq> ralonsoh np at all :)
14:50:11 <fnordahl> slaweq, ralonsoh ok, nw, ta for answer, we'll wait in line :)
14:50:26 <slaweq> ok, lets quickly back to velizarx's RFE https://bugs.launchpad.net/neutron/+bug/1931100
14:51:00 <slaweq> amotoki I see that velizarx just replied to Your comment yesterday
14:51:11 <amotoki> I saw it.
14:51:49 <mlavalle> This last RFE makes sense at first glance
14:52:00 <amotoki> it clarifies what should be shared and I think we can allow network/router association only to end-users with access_as_shared.
14:52:21 <amotoki> I am now fine with this RFE.
14:52:45 <slaweq> thx amotoki, are there any other questions regarding that RFE?
14:52:54 <slaweq> or can we vote on it now?
14:53:06 <mlavalle> mhhh, I said at first glance
14:53:11 <amotoki> slaweq: no more questions from me
14:53:21 <slaweq> I'm +1 on that RFE too
14:53:27 <mlavalle> if you want my vote, can we vote at the beginning of next meeting?
14:54:07 <slaweq> mlavalle we can, of course but next week I will not be able to chair the meeting so I though about cancelling it
14:54:17 <slaweq> in that case we will have next meeting in 2 weeks
14:54:30 <slaweq> if You want, we can wait with this RFE
14:54:39 <mlavalle> of course y'all can go ahead and approve without me. I just don't want to give a +1 without some thinking
14:55:09 <velizarx> Could you give some details about glance? Where is a problem?
14:55:20 <velizarx> I'm a bit out of context
14:55:41 <mlavalle> glance means at first sight
14:55:58 <velizarx> ah :)
14:56:00 <mlavalle> I'm not talking glance the OpenStack project
14:56:54 <mlavalle> slaweq: please feel free to approve this RFE without me. "At first glance" I don't have any concerns
14:56:59 <mlavalle> :-)
14:57:06 <ralonsoh> I think it sounds reasonable but as amotoki said, the spec should define the operations to be allowed
14:57:11 <ralonsoh> so +1 from me too
14:57:27 <velizarx> I have only one question about implementation (if this RFE will be approved ofc) for this RFE. For this RFE I should add BGPV's objects to the main neutron repository (to neutron/objects) but all other code will be in networking-bgpvpn repository. Is it problem?
14:57:42 <slaweq> thx mlavalle and ralonsoh
14:57:53 <slaweq> I will mark rfe as approved
14:57:56 <ralonsoh> no, those objects will live in your repo
14:58:02 <ralonsoh> we can talk about this later
14:58:21 <velizarx> ok, will retrun with this question ;) thx
14:58:32 <slaweq> thank You all for attending the meeting
14:58:35 <amotoki> I think we can skip the spec for this RFE.
14:58:45 <slaweq> we are almost on top of the hour now
14:58:57 <ralonsoh> amotoki, ok then, I'll wait for the patch
14:58:58 <slaweq> amotoki I agree with You
14:59:08 <amotoki> the scope clarifies in the RFE. the API ref and the patch can cover it.
14:59:18 <ralonsoh> perfect
14:59:31 <amotoki> s/clarifies/is clarified/
14:59:50 <slaweq> have a great weekend and see You online :)
14:59:53 <slaweq> #endmeeting