kuraudo has quit [Remote host closed the connection]
kuraudo has joined #openvswitch
kuraudo has quit [Ping timeout: 248 seconds]
kuraudo has joined #openvswitch
moloings has joined #openvswitch
moloings has quit [Client Quit]
moloings has joined #openvswitch
dceara has joined #openvswitch
numans has joined #openvswitch
ChmEarl has joined #openvswitch
mmichelson has joined #openvswitch
imaximets__ has quit [Changing host]
imaximets__ has joined #openvswitch
imaximets__ is now known as imaximets
<mmichelson>
Hi everybody, it's time to begin the weekly OVN developers' meeting.
<dceara>
Hi
<mmichelson>
I can get things started.
<mmichelson>
I've been working closely with _lore_ to try to get incremental processing added to the datapath refactor patch.
zhouhan has joined #openvswitch
<mmichelson>
The reason for this is that dceara tested the datapath and port binding refactor tests with ovn-heater and found that performance was significantly worse as a result, specifically because port binding syncing had to be recomputed on every engine run.
<mmichelson>
In order to get the port binding syncing to have incremental processing, we need the datapaths to have incremental processing too, so that's what we're trying to get done before code freeze.
<mmichelson>
But _lore_ discovered a fundamental issue in the refactor that causes crashes due to invalid pointers to southbound database objects being persisted.
<mmichelson>
So I'm now trying to fix that.
<mmichelson>
I've also contributed some code reviews recently.
<mmichelson>
That's all from me.
<mmichelson>
Who would like to go next?
<imaximets>
May I?
<mmichelson>
sure thing imaximets
<imaximets>
Don't have much, posted a patch to remove the schem parsing from ovn-controller, may post a retis support for system tests soon.
<imaximets>
Next week is branching for OVS 3.6, so spent most of the time on reviews there.
<imaximets>
That's it.
<mmichelson>
Thanks imaximets
<mmichelson>
Who's next?
<dceara>
May I go next?
<mmichelson>
You may dceara
<dceara>
Thanks! :) Ales and I have been working on adding EVPN OVN support - I've been focusing on adding some e2e tests (and infrastructure) and Ales on the actual implementation on top of the RFC I sent for monitoring Linux neighbors.
<dceara>
We're hoping to get something posted for L2 EVPN (what we call our "minimum viable product") before soft freeze.
<dceara>
While doing that I posted a few patches with fixes to bgp related code (and tests).
<dceara>
Not sure if fnordahl is here but it would be nice to get some feedback on all this if he has time.
<dceara>
That's it on my side, thanks!
<fnordahl>
o/
<fnordahl>
(late arrival)
<mmichelson>
dceara, thanks. I saw your MVP patches yesterday. I didn't get a chance to look deeply into them though.
<mmichelson>
Who else would like to give an update?
<moloings>
May I
<dceara>
mmichelson, what's on-list for now is just the infra to monitor linux neighbors. We need a bit more on top of that for MVP. But reviews on the RFC are also welcome.
<mmichelson>
moloings, sure thing!
<moloings>
I am working on adding support for Transit Router to ovn-ic. Currently making ovn-ic-sb.ovsschema changes and ramping on ovn-ic
<moloings>
Thats it from me
<mmichelson>
Thanks moloings.
<mmichelson>
Anyone else?
<zhouhan>
May I
<mmichelson>
zhouhan, yes you may.
<zhouhan>
I spent some time on the ct_proto related HW offload fix with the new approach. Because of this I checked the register usage and found some existing issue, discussed with dceara and I will proceed with the push/pop.
<zhouhan>
I hope to send the patch by end of this week
<zhouhan>
that's it from me
numans has quit [Ping timeout: 260 seconds]
<dceara>
zhouhan, are we going to define a "calling convention"?
<zhouhan>
dceara probably. I will think more on that.
<dceara>
zhouhan, awesome, looking forward to the patch!
<mmichelson>
Thanks for the update zhouhan
<zhouhan>
dceara If it would take too much effort I will first work out the HW offload fix with a explicit push/pop, and optimize with more generic/graceful way later
kuraudo has quit [Quit: kuraudo]
<dceara>
zhouhan, ack
<mmichelson>
Do we have anyone else to give an update?
<fnordahl>
A quick one liner, another crazy week for me, and the multinode test and dceara's EVPN MVP patches are on my list of things to review, I think I'l lock myself in a room one of these days and get it done. We are also working on getting the revert don't skip unsnat patch out to the masses.
<fnordahl>
That's it
<mmichelson>
fnordahl, thanks!
<mmichelson>
Anybody else?
<dceara>
fnordahl, zhouhan, I'm sorry for all the trouble I caused with the "don't skip unsnat..." patch.
<zhouhan>
dceara never say that!
<fnordahl>
Don't mention it, we'vre all guilty of countless bugs, it's the price of progress
<zhouhan>
fnordahl: agree
<mmichelson>
I think that's everyone. Thanks everyone for your time. Have a great day!
<fnordahl>
\o cheers!
<dceara>
Thanks, bye!
<imaximets>
Thanks! Bye.
<mmichelson>
Bye!
mmichelson has quit [Quit: Leaving]
<moloings>
bye
moloings has quit [Quit: WeeChat 4.6.3]
dceara has quit [Quit: Leaving]
<varesa>
ohno, missed people being present by like 5 minutes
<mnasiadka_>
varesa: I think raising that on ovs-discuss mailing list could be beneficial, looking at your issue it might be what is also causing some headaches in my env - but I didn’t have enough time to pin it down like you did ;)
<varesa>
mnasiadka_: thanks for the reply. The mailing list was the next thing I had in mind
<varesa>
... in addition to trying to figure out the code, but that's a rather difficult approach since I'm not too great with C and very unfamiliar with the internal architecture (while I barely am starting to grasp the external interfaces/functionality)
amusil has joined #openvswitch
amusil has quit [Client Quit]
numans has joined #openvswitch
<varesa>
after 50% of time spent trying to get CLion to load the Makefile project and 25% trying to figure out how to make it less optimized in order to make the debugger able to see stuff and 25% frowning on the fact that LLDB can't inspect the hashmaps and only gives a few pointers, I might have an idea
<varesa>
not confirmed/verified yet, but it might be that I have incorrectly the "dynamic" keyword after the MAC on some LSP addresses, where the LS is not set up for DHCP
<varesa>
old address parsing just grabbed the MAC regardless, "new" parsing notices the dynamic keyword and expectes to find an address in the dynamic_addresses which is missing since no DHCP