ArtGravity has quit [Remote host closed the connection]
kuraudo has quit [Ping timeout: 244 seconds]
dceara has joined #openvswitch
kuraudo has joined #openvswitch
mj2 has joined #openvswitch
mkalcok has joined #openvswitch
zhouhan has joined #openvswitch
amusil has joined #openvswitch
<mj2>
hi martin
<mkalcok>
hello o/
<felixhuettner>
hi everyone
<fnordahl>
o/
<amusil>
Hi
<imaximets>
o/
<imaximets>
Hello. It's time to start the weekly OVN meeting.
<imaximets>
Mark is not here today, so I'll host.
<imaximets>
I'll start with my update
<imaximets>
I posted the spine-leaf topology patch set for review.
<imaximets>
Mark too a look, had a few small comments that I need to reply to.
<imaximets>
Other than that, was pretty busy on downstream issues.
<imaximets>
That's all from me.
<imaximets>
And I have a message from Dumitru to pass:
<_lore_>
hi all
<imaximets>
He is upset and dissapointed to not see more review activity upstream. :)
<fnordahl>
imaximets: noted
<imaximets>
(re-phrasing is mine)
<imaximets>
That's all. Who's next?
<fnordahl>
I have an update
<imaximets>
fnordahl, go for it.
<fnordahl>
I've been doing solution level review of the whole BGP epic in context of our intended downstream usage with a CMS such as OpenStack.
<fnordahl>
While doing that I hit a couple of bugs that I posted patches for, thanks for review and merge dceara.
<fnordahl>
While we have discovered some additional work required for one of our in-flight patches, it looks really good to me, and I'll jump into more detailed review of individual patches next.
<fnordahl>
That's it for me
<felixhuettner>
I also have an update
<imaximets>
Thanks, fnordahl !
<imaximets>
felixhuettner, go ahead.
<felixhuettner>
I rebased the northd and ovn-controller BGP patchsets.
<felixhuettner>
Since Martins patch to fix routes without nexthop is now merged in OVS both are actually completely ready.
<felixhuettner>
I could send a fully rebased version now if there is interest.
<felixhuettner>
However it is nearly identical to the branch dumitru posted, with the ovs submodule rebased again.
<felixhuettner>
So i am not sure how much a new version actually helps.
<felixhuettner>
One benefit would be that i could send the northd and ovn-controller patches as one patchset which would allow CI to run completely.
<felixhuettner>
what would be your preference?
<imaximets>
Yeah, we don't have a lot of maintainers today here, but I'd say let's wait a couple days for comments on the current sets, and then rebase with some reviews incorporated?
<felixhuettner>
sounds also good for me
<imaximets>
I know, Dumitru was looking at reviews and _lore_ wanted to take a look as well. So, couple days wouldn't hurt.
<fnordahl>
+1 we've been quite good at building patches off list for this, so that is sufficient for review purposes from my pov
<_lore_>
yep, I will take a look tomorrow
<felixhuettner>
then we can also finish the discussion on "dynamic-routing-redistribute"
<felixhuettner>
and maybe incorporate the changes there
<felixhuettner>
then that would be it from me
<imaximets>
Thanks, felixhuettner ! Sounds good.
<imaximets>
Who wants to go next?
<mkalcok>
on the topic of "dynamic-routing-redistribute", I just wanted to add that I don't have stron prefference and I'll follow whatever convention is chosen for your series felixhuettner
<mkalcok>
(as in, naming convention)
<mkalcok>
and I guess I can give quick update as well
<imaximets>
mkalcok, ack. Sure.
<mkalcok>
I'm working on the changes requested for NAT/LB route advertisement. I was struggling a bit to find a way to set "tracking_port" from the northd side, but I think I found a way forward.
<mkalcok>
thanks for review and feedback from everyone. That's it from me
<zhouhan>
For the HW-offload related CI for upstream patches, we had implemented the framework, but there were security concerns raised from the team.
<zhouhan>
So imaximets I am curious how upstream day-0 robot solve the issue
<zhouhan>
For the patches submitted by anyone there can be malicious code, which could potentially threat the CI environment?
<imaximets>
It's running in a container in an isolated VM in a lab and pushes things to its own github, so it doesn't have a lot of access to the system it runs on, nor the main upstream repo.
<zhouhan>
imaximets: I see. Thanks, we will discuss more internally
<imaximets>
There is always a concern that someone can escape a container and a VM, but it's limited.
<zhouhan>
That's it from me
<imaximets>
zhouhan, thanks!
<imaximets>
Who wants to go next?
<_lore_>
can I go next?
<mj2>
I have a very small update
<mj2>
ah, go first _lore_
<_lore_>
very brief
<imaximets>
_lore_, all yours.
kuraudo has quit [Quit: kuraudo]
<_lore_>
I am working on fixing vxlan with ic
<_lore_>
I do not know if Vladislav is online but I think I am using ic encap types and not 'local' ones
<_lore_>
I think the patch can be improved reviewing the code but I guess it is not breaking his case iiuc what he means
<_lore_>
that's all from me
<_lore_>
thx
<imaximets>
_lore_, ack. Thanks!
<imaximets>
mj2, your turn!
<mj2>
hi
<mj2>
so, i have been working on a multinode system test for the bgp unnumbered effort, alongside frr
<mj2>
this is my first time using the multinode testsuite but im getting there
<mj2>
this is all
<imaximets>
mj2, nice! Much appreciated. Such a test would be very valuable, IMO.
<fnordahl>
imaximets: make sure to relay that to dceara, I'm sure he will be pleased about that
<imaximets>
fnordahl, sure thing. :)
<imaximets>
Do we have anyone else here, who wants to give an update?
<amusil>
I can
<imaximets>
amusil, go right ahead!
<amusil>
Most of the week was with TR making sure it works within ovnk context, there was one issue which should be fixed now
<amusil>
Then I have spent some time looking into performance issue with AS IP and how we process flows for them, there is literally millions of allocations within single function
<amusil>
Still not sure how to avoid that
<amusil>
That's about it, thanks
<imaximets>
amusil, thanks!
<imaximets>
Anyone else?
elvira1 has quit [Ping timeout: 246 seconds]
<zhouhan>
amusil: what's the test scenario of the AS IP?
<amusil>
Adding port with port group which triggers addition of AS
<amusil>
Or not with port group but within port group
<zhouhan>
amusil: just one port addition to a port group?
elvira has joined #openvswitch
<zhouhan>
amusil: that shouldn't trigger many allocations, right?
<amusil>
If there is already few of them, yes
<amusil>
One addition can take 11s in the handler
<amusil>
Just for illustration: util_xalloc 1090.8/sec 272.600/sec 148932.3339/sec total: 536 161 841
<zhouhan>
amusil: It shouldn't be that case. Something seems wrong ...
<imaximets>
FWIW, this number of allocations doesn't look too bad.
<amusil>
Really? If it's just single function doing 90% of that?
<zhouhan>
amusil: In some situation the AS can't be I-P processed which will trigger recompute of the related lflows, if that's the case.
* dceara
joins late and laughs at imaximets way of relaying messages :D
<zhouhan>
imaximets: but 11s sounds really bad
<imaximets>
1000 allocations per second is nothing. Well, not nothing, but not too much.
<amusil>
Yeah 11s for port group handler is bad
<imaximets>
True, just saying that allocations may not be the main consumer of those 11 seconds.
<imaximets>
Did you trace it?
<amusil>
No they are not, but from perf top it's ~20%
<amusil>
Another 10% is hmap lookup
<zhouhan>
amusil: maybe you can check if consider_lflow is triggered (we have coverage counter for that) during your test. If it is triggered then the AS is not I-Ped.
<imaximets>
So, what's the rest 70%?
<amusil>
Smaller things, just few %
<amusil>
The function in question is ofctrl_add_or_append_flow() btw.
<imaximets>
So, it just does too much, it's not the allocations that are the problem, it's general amount of work the function does.
<amusil>
More likely that it's called for every single IP so within one handler run it can be called 100k times
<dceara>
Would a recompute be faster than incremental processing of the address set change in this case?
<zhouhan>
amusil: could you share more details of your test case? If AS is really I-P processed, it is O(1).
<zhouhan>
amusil: If you look at the AS I-P test cases there are scenarios that cannot be I-P processed. I doubt you are hitting those scenarios.
<amusil>
The test case binds 200 ports within loop one by one
<amusil>
The DB has some predefined ACLs and AS
<zhouhan>
amusil: how the ACLs look like matters much
<amusil>
ovnk ACLs don't have them at hand
<imaximets>
Yeah, not every expression can be processed incrementally.
<zhouhan>
amusil: no worries, we can discuss offline, in ML
<amusil>
I'm aware of that, but we are talking about the part when we add the flows into desired hmap
<amusil>
So not the actual parsing etc
<zhouhan>
amusil: if there are only 1 or 2 flows, the performance shouldn't be bad
<zhouhan>
amusil: I mean if only 1 or 2 flows to be added
<amusil>
When we are done the size of desired_flows was around 200MB AFAIR
<zhouhan>
amusil: but if it triggers recompute of the lflow (consider_lflow) then lots of flows to be deleted and re-added, then it would be bad for sure.
<amusil>
This is purely appending conjunctions into existing flows, sometimes it creates new one when the match didn't exist yet
<imaximets>
OK. We may continue this discussion on a list. It's hard to follow without hard data on what's exactly being tested.
<amusil>
Sure
<imaximets>
dceara, you joined late, do you want to share some updates?
<dceara>
Yes!
<dceara>
I'm going to re-rephrase a bit imaximets' relayed message if I may. :)
<dceara>
We're in soft freeze for 25.03 and while there's been a great increase in patch reviews we still have a relatively constant number of patches in the patchwork queue (~40). It would be awesome if we could review all the already posted features to get them into 25.03.0! Thanks again everyone for contributions (patches and reviews/testing)!
<imaximets>
:D
* zhouhan
should be blamed for sure
<dceara>
That's it on my side (been doing reviews and will continue).
<dceara>
Nobody is to blame, I think we're doing great!
<fnordahl>
dceara: ack
<imaximets>
OK. Thanks, dceara !
<imaximets>
Do we have anyone else here who wants to share?
<imaximets>
I guess, not. Thanks, everyone! See you next week.
<imaximets>
Bye!
<dceara>
Thanks, bye!
<felixhuettner>
thanks a lot. bye
<fnordahl>
\o thanks all, cheers!
<zhouhan>
thx, bye
<mkalcok>
o/
mkalcok has quit [Quit: leaving]
<amusil>
Thanks, byt
<amusil>
*bye
amusil has quit [Quit: Client closed]
dceara has quit [Quit: Leaving]
mj2 has quit [Ping timeout: 248 seconds]
ChmEarl has joined #openvswitch
zhouhan has quit [Ping timeout: 240 seconds]
kuraudo has joined #openvswitch
kuraudo has quit [Client Quit]
froyo__ has quit [Ping timeout: 246 seconds]
elvira has quit [Ping timeout: 246 seconds]
unixpro1970 has quit [Remote host closed the connection]