14:00:45 <liuyulong> #startmeeting neutron_l3
14:00:45 <opendevmeet> Meeting started Wed Jun 16 14:00:45 2021 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:45 <opendevmeet> The meeting name has been set to 'neutron_l3'
14:01:07 <liuyulong> L3 meeting should be here?
14:01:43 <haleyb> yes, and hi.  i am in training so might be more lurking
14:02:46 <lajoskatona> Hi
14:03:19 <liuyulong> OK, cool, I think more Neutron developers should attend the meeting by default if they are in this channel.
14:03:52 <liuyulong> #topic Announcements
14:04:45 <liuyulong> The meeting boot does not response to the topic change?
14:05:40 <liuyulong> OK, I see someone said that "#topic" not work now.
14:06:52 <liuyulong> We change the meeting channel for L3 subteam, this is the only thing I want to mention in this section.
14:06:55 <liuyulong> #link https://meetings.opendev.org/#Neutron_L3_Sub-team_Meeting
14:08:19 <liuyulong> We have changed the IRC channels for all Neutron meetings to  #openstack-neutron
14:08:48 <lajoskatona> liuyulong: there are issues with chatbot, so perhaps this is just one of those
14:08:51 <liuyulong> OK, no more announcements. Let's move on.
14:10:01 <liuyulong> lajoskatona, I see the "topic issue" both in channel #openstack-meeting-alt and #openstack-nova. They just said the same thing there.
14:10:18 <liuyulong> #topic Bugs
14:10:52 <liuyulong> First one
14:10:53 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1926531
14:12:13 <liuyulong> I should say sorry, too many things bothered me that I forgot to submit the related fix.
14:13:57 <liuyulong> This should be easy to fix, just check if there are floating IPs services by the DVR local router. If yes, do not run the veth pair device clean up action.
14:15:10 <liuyulong> Next one
14:15:12 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1926045
14:16:18 <liuyulong> As I said before, such behaviour should be the feature. But the reporter re-open it, so let's wait what he/she will response.
14:16:32 <liuyulong> Next one
14:16:33 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1930200
14:17:02 <liuyulong> "[RFE] Add support for Node-Local virtual IP" I guess, I should add the bug title here.
14:18:36 <liuyulong> This RFE has been approved. I just left some comments there, the main concern from me is how the packet transmit on the datapath (flows).
14:22:33 <liuyulong> if i understand correctly, when VMs are going to communit with a "Node-Local virtual IP". The destination IP address will be changed to another VM's fixed IP.
14:24:16 <liuyulong> #link https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-06-04-14.01.log.html#l-22
14:25:07 <liuyulong> ^^^ this is the discussion about this RFE.
14:26:04 <liuyulong> They just mentioned "169.254.169.254", so my thougth is just based on that.
14:27:05 <liuyulong> OK, last one
14:27:06 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1931953
14:27:19 <liuyulong> "[RFE] Openflow-based DVR L3"
14:27:48 <liuyulong> Another flow based L3 request.
14:27:54 <haleyb> wasn't there a proposal for this before that we decided to not complete?
14:28:01 <liuyulong> We already have https://bugs.launchpad.net/neutron/+bug/1705536 and https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr
14:28:01 <ralonsoh> this is an old RFE, there are some old patches
14:28:24 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1931953/comments/1
14:28:28 <haleyb> right, and we said let's use OVN instead
14:28:38 <liuyulong> Yes, I mentioned to the reporter about all these information.
14:28:49 <ralonsoh> IMO this should be discussed in the drivers meeting
14:29:03 <lajoskatona> agree
14:29:21 <ralonsoh> I'll add the topic
14:31:12 <liuyulong> Actually I would like to see if python based neutron agents can achive a higher performance by using ovs flows (dpdk) for L3 functionalities.
14:31:35 <ralonsoh> for sure it will
14:31:53 <ralonsoh> but the problem is the complexity of the code, as I remember when I was helping David on this
14:32:01 <ralonsoh> and all the corner cases
14:32:18 <liuyulong> And, for python neutron agents, such solution should be easily to upgrade for existing cloud.
14:33:09 <liuyulong> ralonsoh, yes, DVR is really complicated, too many cases should be covered.
14:35:57 <liuyulong> From my personal experiences, Neutron L3 functionalities are now based on kernel network stack (datapath) which can not meet increasing performance requirements in real production cloud.
14:36:43 <ralonsoh> yeah, this is a know problem. For sure offloading the processing to OF rules could speed up that
14:37:05 <ralonsoh> of course, the complexity of this change could be huge
14:37:25 <ralonsoh> and I don't know, now having OVN, if that could be relevant
14:38:02 <liuyulong> But current implementation has a very very advanced alternatives is to translate the iptables to eBPF which is in userspace with high performance.
14:39:25 <ralonsoh> well, all kernel filtering has been merged in one single tool, nft
14:39:26 <liuyulong> New kernel supports that, but it is very experimental.
14:39:51 <ralonsoh> I don't know if going through this path has any benefit
14:39:58 <ralonsoh> instead of spending time on nft
14:42:40 <liuyulong> There are some works is to offload iptables rules to BPF program transparently. So maybe we just use the iptables to set the rules as we do now, then everything done by the kernel In an ideal state. :)
14:43:44 <liuyulong> ralonsoh, can OVN use ovs-DPDK to accelerate packet trasimit rate?
14:44:00 <ralonsoh> for sure and HW offload
14:46:03 <liuyulong> #link https://docs.openstack.org/networking-ovn/latest/admin/dpdk.html
14:46:40 <ralonsoh> we can discuss about this offline
14:46:43 <liuyulong> Maybe we can write something about the performance increment in this doc.
14:46:47 <ralonsoh> I think we have better documentation
14:46:52 <ralonsoh> *updated
14:47:38 <liuyulong> #topic On demand agenda
14:47:45 <liuyulong> OK, we still have sometime.
14:48:13 <liuyulong> Firstly, I'd like to request the team to review the code https://review.opendev.org/q/topic:%22bp%252Fdistributed-dhcp-for-ml2-ovs%22+(status:open%20OR%20status:merged)
14:48:41 <ralonsoh> I'll add them to my pile
14:48:53 <liuyulong> It almost done. Then we can say someday the DHCP agent can get retired.
14:49:40 <lajoskatona> Good question to have job for this later in CI
14:49:43 <liuyulong> So... I have another request about the metadata-agent, I want to make it distributed.
14:49:58 <liuyulong> And someday make metadata-agent retired...
14:51:22 <liuyulong> Since it is single function, just used during VM booting time mostly.
14:52:55 <liuyulong> So, in the foreseeable future, neutron will only run ovs-agent and L3-agent. If we can get higher datapath performance by ovs-based (securigy group, L3 and so on).
14:54:05 <liuyulong> Then another thing about Neutron we should take care should be the control plane performace.
14:57:23 <liuyulong> Recently I was thinking a problem about can we create 100/200/300K VMs into one single network. Can Neutron L2 pop handle that? Can OVN handle that?
14:57:49 <ralonsoh> not at all
14:59:52 <liuyulong> OK, just throw out some ideas, and hope everyone can think about it. We still have a long way to go. :)
15:00:00 <liuyulong> Alright, time is up.
15:00:06 <liuyulong> Thank you guys.
15:00:08 <ralonsoh> bye
15:00:15 <liuyulong> #endmeeting