17:17:31 #startmeeting ovn_community_development_meeting 17:17:32 Meeting started Thu May 6 17:17:31 2021 UTC and is due to finish in 60 minutes. The chair is imaximets. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:17:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:17:36 The meeting name has been set to 'ovn_community_development_meeting' 17:17:50 Thanks imaximets 17:17:58 I have some updates. 17:18:20 First is that OVSDB 2-Tier patch-set finally posted 17:18:51 #link https://patchwork.ozlabs.org/project/openvswitch/list/?series=241642 17:19:09 I also sent today a patch for raft 17:19:32 to transfer leadership before starting database compaction 17:19:48 #link https://patchwork.ozlabs.org/project/openvswitch/patch/20210506124731.3599531-1-i.maximets@ovn.org/ 17:20:16 the problem is that database compaction/snapshotting could take a lot of time if database is big 17:20:28 It's a good idea. Thanks for writing it up. 17:20:48 e.g 200-500MB of on-disk data. It takes 2-15 seconds to create a snapshot 17:21:13 and cluster is not functional if the server that creates a snapshot is a leader. 17:21:35 transferring the leadership makes the system more stable. 17:21:58 and the last update: 17:21:59 Wow, that's a lot. I never did measurements. 17:23:00 I also worked few weeks ago on a patch for OVN to collapse ARP responder flows. 17:23:22 Excellent. 17:23:29 On some setups these flows could take half of the southbound db. 17:23:39 wow 17:23:50 In my case it was almost 250MB out of 500MB database. 17:24:10 And the change actually reduced the db size in half. 17:24:22 imaximets++ 17:24:28 that's great 17:24:47 I have a patch, but I don't have a ddlog part yet. 17:25:21 it looks like this: https://github.com/igsilya/ovn/commit/732365025682cdb2987d601d3caedee1a94dfcf7 17:26:21 the idea is to simplify the actions (i.e. remove dependency from addresses) and put all load balancer IPs into one lflow instead of creating a separate lflow for all of them. 17:26:55 Alternatively this could be done with the address set. I'll probably will go with the address set for the final patch. 17:27:03 Wonderful. 17:27:31 IIRC, tomorrow is the deadline to submit v1 for 20.06? 17:27:35 *21.06 17:28:33 So, I will post some version of the patch tomorrow. And will work it out later if will not be able to figure out ddlog parts until then. 17:28:38 imaximets combining flows may have some implication on I-P processing (maybe that's not a problem for this case, but we need to be careful) 17:29:38 I upgraded to Fedora 34 and therefore GCC 11 and I'm getting some new warnings for OVS. I didn't notice anyone posting patches for these already, has anyone else? 17:29:44 zhouhan, sure. But in this case shrinking the database in half is kind of important too, because ovsdb-server just cant handle it. 17:30:15 blp, I have a 'may be uninitialized' in netdev-dummy. 17:30:37 OK, this is different. I'll fix and post. 17:30:42 imaximets yes. CPU & MEM sometimes need trade-offs 17:31:01 blp, thanks! 17:31:21 ok. that was it from my side. 17:31:28 who will go next? 17:31:51 I just have a quick report 17:32:01 blp, go ahead. 17:32:02 which is that I'm getting back to fixing up my patch series and will repost. 17:32:24 Sorry I disappeared for a while. 17:33:00 <_lore_> can I go next? quite fast 17:33:29 _lore_, sure, if that's all from blp? 17:33:38 <_lore_> blp: yes, sorry 17:33:54 Oh, I think that's all. 17:34:08 If I think of more, I'll add it. 17:34:20 Oh, one thing is that we got a paper about OVS accepted at SIGCOMM. 17:34:51 congrats! 17:34:58 blp, cool! 17:35:21 ok, _lore_ , your turn. 17:35:29 <_lore_> ok, last week I worked on CoPP series, I added unit/system tests and remove per-port metering, posted v1 upstream 17:35:35 <_lore_> http://patchwork.ozlabs.org/project/ovn/list/?series=241400 17:36:04 <_lore_> I guess we can continue discussing from v1 about possible changes on API and so on 17:36:49 <_lore_> I added a fix for localport --> localnet traffic 17:36:50 <_lore_> http://patchwork.ozlabs.org/project/ovn/patch/8008fa9867d210cf18ad31f912535f2c14e85c43.1620151078.git.lorenzo.bianconi@redhat.com/ 17:37:19 <_lore_> and I have a pending debug patch out for review 17:37:21 <_lore_> http://patchwork.ozlabs.org/project/ovn/patch/3a9ca2d94478a3b2db51d719233c9a28cafcf75b.1619268349.git.lorenzo.bianconi@redhat.com/ 17:37:29 <_lore_> that's all from my side, thx 17:38:02 I can go next 17:38:12 _lore_, thanks! 17:38:16 zhouhan, sure. 17:38:33 This patch still needs review: https://patchwork.ozlabs.org/project/ovn/patch/20210504013332.1689887-1-hzhou@ovn.org/ 17:38:50 The last version addressed Mark M 17:39:04 's comments about test case improvement 17:39:24 zhouhan, I'll have a look at that this afternoon. I plan to review that plus a patch of numans's 17:39:28 (btw, I'm back now) 17:39:40 mmichelson cool. thanks a lot! 17:40:34 I was also checking DP group. I think there is a small problem on the MC_UNKNOWN flow handling. I have a fix and will send out today 17:41:24 zhouhan, we're not using DP groups for multicast groups. Or the issue is that we are doing that somewhere? 17:42:02 imaximets yes, I think it is just missed for the MC_Unknown group. It is using DPG :) 17:42:18 the fix is simply not using DPG for the flow 17:42:39 zhouhan, oh, ok. Sounds good. :) 17:43:01 It also seems that DP group could have a higher CPU cost in ovn-controller when dealing with port group changes for ACL flows, because each change would have be bigger impact with the DPG enabled. But I will study more on this. 17:43:25 * imaximets thinks that we still need to fix dependencies somehow between multicast groups and lflows. 17:43:32 imaximets also, any plan to make DPG work in DDlog version? (Or is it already supported but I missed somehow?) 17:44:03 I thought it was supported there 17:44:09 zhouhan, should be supported. There is a test for them. blp should know, I think. 17:44:45 When you run a test with OVN_FOR_EACH_NORTHD now, it will run four versions: C with DP groups, C without DP groups, DDLog with DP groups, and DDLog without DP groups 17:45:27 zhouhan, "ovn -- logical gatapath groups" should work for all implementations, so it should be supported. 17:46:20 datapath groups? I think that they are supported. 17:46:21 in ddlog 17:46:43 test 17:46:51 Wow, that's a lot of variations, 4x for each of those? 17:47:11 Yep 17:47:37 blp, unit tests are a bit slow now. :) but that's for good. 17:47:40 The worst part of the OVN_FOR_EACH_NORTHD stuff is that it doesn't report line numbers very well. 17:47:52 If anyone figures out how to do that better, that'd be great. 17:48:10 zhouhan56: we see you 17:48:43 hi I'm back 17:48:52 zhouhan56 cannot talk :( 17:49:01 zhouhan, hi. :) 17:49:12 sorry I was disconnected for a while 17:49:32 zhouhan, we concluded that DPG supported in ddlog. 17:49:46 zhouhan: welcome back 17:49:49 imaximets oh, great. Sorry I missed that 17:50:32 zhouhan, for the performance, IIRC, there was a lot of issues with I-P engine, so I had to sacrifice some performance on the ovn-controller side. 17:50:48 i.e. I-P is not ideal with DPG. 17:51:37 imaximets: yes there is some challenge, but I will see if there is a way to make DPG work well with I-P 17:51:51 zhouhan, that would be great. thanks! 17:51:51 MEM and CPU are both important for some of our environment :) 17:52:03 the last thing I said before disconnecting was: imaximets the dependency part I think I also have a fix in mind, will work on it as well 17:52:44 Apart from these, I did review of numans CT patches 17:52:48 zhouhan, nice. this also would be great to have. 17:53:23 Thanks numans for the I-P improvement, but I'd like to discuss more on that patch 17:53:28 that's my update 17:53:50 ok. Who wants to go next? 17:53:59 I can go next 17:54:13 mmichelson, all yours. 17:54:36 I have two main things I've worked on recently. First is the ARP-related patch series. I posted a v7 of it where I ended up whitelisting a warning message from ovn-controller that had been causing systems tests to fail 17:55:00 I've talked that particular issue over with imaximets and dceara and dceara suggested a possible workaround that I'm going to look into. 17:55:15 v7 also triggered 0-day robot since the line length checks are working again in checkpatch.py 17:56:13 The other thing I'm working on is an issue where the same conjunction() action can appear multiple times in a flow. I figured out the issue, it's a one-line fix in expression code. The explanation of the issue and the fix will take probably 50x more lines than the actual fix. 17:56:33 That particular fix should hit the mailing list later today 17:57:01 Other than that, we're approaching soft freeze tomorrow. So any patches that you want included in 21.06.0 should be posted by tomorrow. 17:57:11 That's all from me. 17:57:32 I posted my GCC 11 series: https://patchwork.ozlabs.org/project/openvswitch/list/?series=242511 17:57:40 (It's for OVS, not OVN.) 17:58:23 blp, thanks, I'll take a look. 17:58:27 blp, is there a pending OVN patch, too? 17:58:56 mmichelson shall we release 20.03.1 anytime soon? 17:59:06 sorry, 21.03.1 17:59:43 zhouhan, sure, we can do that when we release 21.06.0 18:00:07 mmichelson: I'll look at OVN now. 18:00:18 mmichelson ok, thanks! 18:01:23 Good. Anyone else has updates? 18:02:34 OK. In this case we can close this meeting. Have a nice day! 18:02:39 #endmeeting