Thursday, 2020-09-03

*** JamesBenson has quit IRC00:08
*** JamesBenson has joined #openvswitch00:09
*** grive has quit IRC00:20
*** grive has joined #openvswitch00:20
*** thaller_ has quit IRC00:32
*** thaller__ has joined #openvswitch00:32
*** acidfu has quit IRC01:12
*** acidfu has joined #openvswitch01:28
*** acidfu has quit IRC01:34
*** JamesBenson has quit IRC01:35
*** grive has quit IRC02:13
*** grive has joined #openvswitch02:13
*** armax has quit IRC02:17
*** acidfu has joined #openvswitch02:34
*** JamesBenson has joined #openvswitch03:05
*** JamesBen_ has joined #openvswitch03:09
*** JamesBenson has quit IRC03:10
*** dcbw has quit IRC03:25
*** zhouhan_ has quit IRC03:49
*** zhouhan has joined #openvswitch03:50
*** zhouhan_ has joined #openvswitch03:52
*** zhouhan has quit IRC03:55
*** zhouhan has joined #openvswitch03:56
*** zhouhan_ has quit IRC03:58
*** JamesBen_ has quit IRC04:39
*** anilvenkata has joined #openvswitch04:39
*** osmanlicilegi has quit IRC04:40
*** osmanlicilegi has joined #openvswitch04:40
*** osmanlicilegi has quit IRC04:40
*** osmanlicilegi has joined #openvswitch04:41
*** anilvenkata_ has joined #openvswitch04:42
*** anilvenkata has quit IRC04:44
*** acidfu has quit IRC04:51
*** acidfu has joined #openvswitch04:52
*** JamesBenson has joined #openvswitch05:00
*** acidfu has quit IRC05:08
*** JamesBenson has quit IRC05:32
*** JamesBenson has joined #openvswitch05:33
*** JamesBenson has quit IRC05:38
*** jaicaa has quit IRC05:49
*** dholler has joined #openvswitch05:49
*** jaicaa has joined #openvswitch05:52
*** eelco has joined #openvswitch05:56
*** links has joined #openvswitch06:34
*** JamesBenson has joined #openvswitch06:38
*** JamesBenson has quit IRC06:43
*** JamesBenson has joined #openvswitch07:06
*** ralonsoh has joined #openvswitch07:11
*** JamesBenson has quit IRC07:24
*** zhouhan has quit IRC07:38
*** zhouhan has joined #openvswitch07:38
*** darkemon has joined #openvswitch08:08
*** thaller_ has joined #openvswitch08:33
*** thaller__ has quit IRC08:35
*** darkemon has quit IRC08:53
*** rcernin has quit IRC10:01
*** JamesBenson has joined #openvswitch11:00
*** JamesBenson has quit IRC12:04
*** JamesBenson has joined #openvswitch12:19
*** JamesBenson has quit IRC12:23
*** dholler has quit IRC12:36
*** dholler has joined #openvswitch12:37
*** ralonsoh has quit IRC12:51
*** ralonsoh has joined #openvswitch12:52
*** rcernin has joined #openvswitch13:00
*** rcernin has quit IRC13:04
*** dholler has quit IRC13:07
*** dholler has joined #openvswitch13:08
*** seliopou has quit IRC13:14
*** seliopou has joined #openvswitch13:16
*** armax has joined #openvswitch13:20
*** JamesBenson has joined #openvswitch13:25
*** dcbw has joined #openvswitch13:32
*** acidfu has joined #openvswitch14:00
*** links has quit IRC14:04
*** ralonsoh has quit IRC14:41
*** ralonsoh has joined #openvswitch14:42
*** dcbw has quit IRC15:21
*** dcbw has joined #openvswitch15:21
*** eelco has quit IRC15:25
*** anilvenkata_ has quit IRC15:32
*** blp has joined #openvswitch17:08
blpHi! I made it to the meeting today.17:14
zhouhanHi blp!17:16
*** Ankur1 has joined #openvswitch17:16
*** Ankur150 has joined #openvswitch17:16
flaviofhi all!17:17
Ankur1Hi17:17
numansHi all17:17
numansblp, Hi.17:17
imaximetsHi17:17
numansI think mmichelson will not be joining.17:17
numansI'll start the meeting17:18
numans#startmeeting ovn_community_development_discussion17:18
openstackMeeting started Thu Sep  3 17:18:07 2020 UTC and is due to finish in 60 minutes.  The chair is numans. Information about MeetBot at http://wiki.debian.org/MeetBot.17:18
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:18
openstackThe meeting name has been set to 'ovn_community_development_discussion'17:18
numansWho wants to go firat17:18
numanss/firat/first17:18
zhouhanI can go first17:19
numanssure17:19
zhouhanI improved the nb_cfg mechanism with timestamp which measures end to end latency more accurately17:19
zhouhanWith that, I retested the incremental flow installation patch series, and can measure the actual latency improvement (in addition to CPU cost).17:20
_lore_hi all17:20
zhouhanI could also spin up 3k HVs with 30k lports in scale test, with only 15 farm nodes, thanks to all the ovn-controller CPU improvements.17:21
zhouhanwith this env, the processing time of both ovn-northd and all ovn-controllers, the end to end latency is reduced by 30%.17:21
zhouhanIf considering ovn-controllers only (the total time spent on processing SB lflow change by all HVs), the latency reduced by 60%.17:22
numanszhouhan, that's great.17:22
flaviofzhouhan: does that use the private_chassis table? Is that relevant in your test?17:22
numanszhouhan, does your testing also include your ofctrl I-P patches ?17:22
zhouhanAnd now the total e2e latency is 1.5 seconds, which is not bad considering the scale 3K HVs and 30k lports17:22
zhouhanflaviof: yes, private_chassis table, with timestamp17:23
flaviofzhouhan: nice!17:23
zhouhannumans: yes, the 30% and 60% improvement I mentioned is for the ofctrl I-P patches.17:23
numansok17:24
blpI have a new 3990X desktop that I'm going to use for benchmarking OVN. It should do a good job.17:24
zhouhannumans: please take a look when you have time. #link https://patchwork.ozlabs.org/project/openvswitch/list/?series=19700917:24
numanszhouhan, ack. If I understand you store the timestamp in the db right ?17:25
numansblp, cool.17:25
zhouhanFor the nb_cfg improvements, it is: #link https://patchwork.ozlabs.org/project/ovn/list/?series=19896217:25
zhouhanI also submitted a patch that optionally avoids checking lsp_is_up for programming ARP responder flows17:26
zhouhanI think in most cases we don't need this check, and it would largely reduce the cost of the control plane, for port creation and binding - around half of the cost17:27
numanszhouhan, ok. So the option is added per ls ? or lsp ? or globally ?17:27
numansI didn't see the patch yet17:28
zhouhannumans: globally17:28
numanszhouhan, ok. sounds good17:28
zhouhannumans: the patch is here #link https://patchwork.ozlabs.org/project/ovn/patch/1599099225-113525-1-git-send-email-hzhou@ovn.org/17:29
numansack17:29
zhouhanI am also thinking of adding support for directly specifying port-binding chassis from NB, to avoid port-binding updates from chassises. I think this may be useful for some use cases, probably k8s? (at least it is useful for me)17:29
*** gregwork has quit IRC17:29
zhouhanThat's my update :)17:30
numansThanks. Who wants to go next17:30
flaviofzhouhan: specifying port-binding chassis from NB instead of .... ?17:31
Ankur1Can i go next?17:31
zhouhanoh, I forgot one thing. For e2e latency 1.5 sec, 1 sec is in ovn-northd.17:31
zhouhanThanks blp for the update on DDlog progress17:31
zhouhanI think it is the next biggest improvement for the e2e latency17:32
zhouhanflaviof: instead of updating from chassis to SB.17:32
zhouhansorry Ankur1. Please go ahead.17:32
flaviofzhouhan: ack. Ankur1 sorry for the interrupt17:33
Ankur1Thanks a lot zhouhan. No problem at all flaviof.17:34
Ankur1 Just wanted to highlight a couple of problem statements we are working on and wanted to get some opinion on one of the solutions.17:34
Ankur1a. We are getting plenty of scenarios where there is a need to support multiple distributed gateway router ports per logical router.17:34
Ankur1Does not look like a trivial scenario to solve, but just wanted to highlight we have started some efforts around this.17:34
*** acidfu has quit IRC17:35
blpzhouhan: I'm embarrassed that I haven't had progress updates in a while.17:35
Ankur1b. Flushing of CT zones: As of now the logic is tied with the existence of datapath. However, there are scenarios where datapath is still existent but CT zone should be flushed (for example if just remove all the NAT rules from a router).17:36
*** thaller has joined #openvswitch17:37
Ankur1For b. i submitted a patch some time back, however patch was handling the LB case, hence we abandoned it.17:37
Ankur1As of now, to make CT FLUSH by ZONE more generic, we are thinking if we can add something like CT_FLUSH_BY <ZONE, CT_MARK>, where CT_MARK indicates if a CT entry is because of NAT or LB (or some other feature).17:37
Ankur1Its the CT_FLUSH_BY <ZONE, CT_MARK> where wanted to seek some opinions and thoughts here.17:38
numansAnkur1, for LB, we already set ct_label[1]17:38
*** thaller_ has quit IRC17:38
numansct_label.natted is the logical field17:38
Ankur1Cool, let us say CT_FLUSH_BY <ZONE, CT_LABEL>..17:39
numansAnkur1, I'm not sure If I'm following what CT_FLUSH_By <..> would do.17:40
numansMay be you can send an email to the ML about your proposal and we could discuss there.17:41
numansthanks for the efforts for all these features.17:41
Ankur1Sure, what i mean is that as of now we have CT_FLUSH_BY <ZONE>, and we are thinking if we make is more granular CT_FLUSH_BY <ZONE, LABEL>, where LABEL identifies a feature.17:42
Ankur1We want to achieve following:17:42
Ankur1a. Trigger CT ZONE flush through config detach/attach rather than datapath delete/add.17:42
Ankur1b. Do CT ZONE FLUSH by feature, so that we are flushing the whole zone, but rather just for a feature, like NAT, LB etc.17:42
Ankur1Sure, i will send out more details in ML. Just wanted to provide a summary here :)17:42
Ankur1Thats all from my side.17:42
numansAnkur1, cool.17:42
zhouhanthanks Ankur1. a) sounds reasonable. I tried to do it once, but it seemed tricky in the code. So I instead worked around it by creating multiple routers and peering them with static routes. It would be great if the code can be improved to support the use case.17:43
zhouhanblp: no worries, as long as it is in progress :) numans and I wondered if we need a temporary I-P for northd before DDlog version is ready, which was why I wanted to know where we are in the DDlog progress first.17:43
zhouhannumans: do you want to talk about your idea, since blp is here today17:45
blpnumans: Please tell me about it.17:45
numansMy idea was to add a simple I-P engine which would not recompute for unnecessary db changes to start with - like nb_cfg change.17:46
blpSo, here's what needs to happen for the DDlog OVN:17:46
blp1. Benchmark.17:47
blp2. Update to whatever hasn't made it in.17:47
blpThat's all, I think.17:47
blpIt would be easier to maintain if folks were OK with merging it before #1 and #2 happened.17:47
blp#2 in particular is a treadmill.17:47
numansblp, by merging you mean replacing the c version ? or we have both in parallel ?17:48
blpHaving both in parallel.17:48
zhouhanblp: yes, I feel #2 is hard, too, since ovn-northd is still changing very often.17:48
blpThat's the way it is in the current fork: both versions get built.17:49
numansIt sounds good to me.17:49
numansAnd we can switch over to ddlog as default when we have (1) comparable to 'C'.17:49
blpOK, then I will plan to post patches in the next few weeks.17:49
zhouhanSounds good to me, too, as long as there are no major issues (except the feature gap)17:50
blpThe feature gap is really just whatever has been added in the last few months.17:50
numanszhouhan, blp when we have feature gap addressed, we can have the patch submitters to update both the versions17:51
zhouhanI assume the benchmark should be better than C, according to some very basic testing I did last year (and now a year past)17:51
numansotherwise we will always have delta between the two17:51
blpI am sure that some tuning and iteration will be needed, because this is the biggest DDlog program that has been written, much bigger than any other.17:52
zhouhan"when we have feature gap addressed" - maybe this is the hardest part. How to achieve that/17:52
numanszhouhan, may be we can dedicate the next release to ddlog ?17:53
numansafter branching for 20.0917:53
zhouhanblp: last year my test showed it 90% more efficient than the C version. Even without further tuning, I assume it shouldn't degrade too much after adding more features recently, right?17:53
blpzhouhan: You are probably right.17:53
zhouhannumans: I am ok with that.17:54
zhouhanwould a feature freeze for ovn-northd helpful?17:54
blpzhouhan: At some point, yes.17:54
numanszhouhan, I actually meant that. once we branch for 20.09, we can work on closing the gaps and until then no new features.17:55
zhouhannumans: sounds good to me, but not sure about the broad community :)17:55
numanszhouhan, we can discuss on this in ML.17:56
zhouhansure17:56
numansblp, thanks for all the efforts17:57
flaviofblp: hi! stupid q on ddlog: rust dependency will be part of ovn, but not needed for ovs codebase at all, right? I hear the compiling will take longer with rust. Is that noticeable to you?17:57
blpflaviof: OVS will not need rust.17:57
blpflaviof: For now, it will be an optional dependency for OVN. Without Rust, you won't get the DDlog version.17:57
flaviofack. #link http://www.openvswitch.org/support/ovscon2019/day1/1553-OVS-OVN'19%20-%20DDlog%20in%20OVN.pdf ovscon talk on ddlog changes17:58
* zhouhan have to drop off in 1 min, will read your discussion offline17:58
flaviofblp: thanks!17:58
blpflaviof: Compiling definitely takes noticeably longer. Most of the time, incremental compilation is not much slower, but the first build takes longer.17:58
flaviofblp: fair enough. it is one time cost vs runtime gains. a good trade17:59
numanszhouhan, bye17:59
numansblp, anything else on the ddlog topic ? If not, I can go next real quick18:00
flaviofblp on next ovscon I anticipate an update on that talk that Mark+Dumitru gave. ;)18:00
blpnumans: That is all I have.18:00
numansthanks.18:00
numansI can go next real quick.18:01
numansI submitted the patch series to cache lflow expr matches/expr tree.18:01
numans#link https://patchwork.ozlabs.org/project/ovn/list/?series=19914418:01
numansI was behind reviews. I started reviewing some of the patches.18:01
numansI also submitted a patch to handle cluster db upgrades for run_xx_ovsdb ovn-ctl commands.18:01
numans#link https://patchwork.ozlabs.org/project/ovn/patch/20200903130400.1971690-1-numans@ovn.org/18:02
numansRequest to take a look at these patches.18:02
numansThat's all from me.18:02
numanswho wants to go next ?18:03
_lore_I can go next?18:04
_lore_very quick18:04
_lore_I posted some ovs/ovn patch for review18:04
_lore_ovs: I added some debug code for raft18:04
*** Ankur150 has quit IRC18:05
_lore_ovn:18:05
_lore_- dhcp decline msg support for dhcp18:05
_lore_- running ovs_db with valgrind/strace18:05
_lore_- a fix for IPv6 empty_lp controller_event18:06
_lore_now I restarted working on ovn-scale code18:06
_lore_that's all from my side, thx18:06
*** acidfu has joined #openvswitch18:07
numans_lore_, thanks.18:09
numansanyone else ?18:10
numansIf not we can probably end the meeting.18:10
flaviofI was on pto last week; not much to report other than small nits on ovn-fake-multinode18:11
flaviof#link https://github.com/ovn-org/ovn-fake-multinode/pull/3618:11
flaviofthat is all from me :)18:11
numansflaviof, thanks for the PR.18:11
numansOk. Everyone. Let's end the meeting.18:12
numansBye18:12
flaviofbye all!18:12
numans#endmeeting18:12
openstackMeeting ended Thu Sep  3 18:12:41 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:12
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-09-03-17.18.html18:12
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-09-03-17.18.txt18:12
openstackLog:            http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-09-03-17.18.log.html18:12
*** blp has quit IRC18:12
_lore_bye18:16
flaviofbb _lore_ !18:17
*** acidfu has quit IRC18:43
*** fab23 has quit IRC18:53
*** fab23 has joined #openvswitch19:00
*** acidfu has joined #openvswitch19:00
*** acidfu has quit IRC19:05
*** Ankur1 has left #openvswitch19:12
*** ralonsoh has quit IRC19:30
*** slaweq has quit IRC20:20
*** slaweq has joined #openvswitch20:26
*** rebrec has quit IRC20:46
*** JamesBenson has quit IRC20:51
*** JamesBenson has joined #openvswitch21:08
*** dcbw has quit IRC21:25
*** rcernin has joined #openvswitch23:25
*** donhw_ has quit IRC23:25
*** donhw has joined #openvswitch23:28
*** rcernin has quit IRC23:31
*** rcernin has joined #openvswitch23:31

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!