racosta_ has quit [Remote host closed the connection]
racosta_ has joined #openvswitch
ihrachys has joined #openvswitch
ChmEarl has quit [Quit: Leaving]
larsd has quit [Remote host closed the connection]
ihrachys has quit [Ping timeout: 252 seconds]
jsn has joined #openvswitch
ihrachys has joined #openvswitch
ihrachys has quit [Ping timeout: 244 seconds]
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #openvswitch
jsn_ has joined #openvswitch
jsn has quit [Ping timeout: 260 seconds]
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #openvswitch
donhw has quit [Read error: Connection reset by peer]
jraju__ has joined #openvswitch
jsn_ has quit [Ping timeout: 252 seconds]
donhw has joined #openvswitch
ihrachys has joined #openvswitch
ihrachys has quit [Ping timeout: 245 seconds]
froyo__ has joined #openvswitch
kuraudo has joined #openvswitch
elvira has joined #openvswitch
_lore_ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
_lore_ has joined #openvswitch
ihrachys has joined #openvswitch
ihrachys has quit [Ping timeout: 265 seconds]
jsn_ has joined #openvswitch
jraju__ has quit [Ping timeout: 244 seconds]
ihrachys has joined #openvswitch
ihrachys has quit [Ping timeout: 272 seconds]
jraju__ has joined #openvswitch
jsn_ has quit [Ping timeout: 244 seconds]
donhw has quit [Read error: Connection reset by peer]
kuraudo has quit [Quit: kuraudo]
donhw has joined #openvswitch
kuraudo has joined #openvswitch
tpires_ has joined #openvswitch
ihrachys has joined #openvswitch
jsn_ has joined #openvswitch
jraju__ has quit [Ping timeout: 260 seconds]
ihrachys has quit [Ping timeout: 246 seconds]
jraju__ has joined #openvswitch
jsn_ has quit [Ping timeout: 260 seconds]
ihrachys has joined #openvswitch
jsn_ has joined #openvswitch
jraju__ has quit [Ping timeout: 246 seconds]
elvira has quit [Ping timeout: 260 seconds]
elvira has joined #openvswitch
dceara has joined #openvswitch
elvira has quit [Ping timeout: 252 seconds]
elvira has joined #openvswitch
jraju__ has joined #openvswitch
jsn_ has quit [Ping timeout: 260 seconds]
elvira has quit [Ping timeout: 245 seconds]
elvira has joined #openvswitch
jraju__ has quit [Ping timeout: 260 seconds]
elvira has quit [Ping timeout: 245 seconds]
ihrachys has quit [Ping timeout: 260 seconds]
ChmEarl has joined #openvswitch
ihrachys has joined #openvswitch
mmichelson has joined #openvswitch
GNUmoon has quit [Ping timeout: 260 seconds]
amusil has joined #openvswitch
GNUmoon has joined #openvswitch
zhouhan has joined #openvswitch
<mmichelson>
Hi everyone. It's time to begin the weekly OVN developers' meeting.
<amusil>
Hi
<_lore_>
hi all
<mmichelson>
My update is that I've started from scratch on the composable OVN services/boxes idea, and hope to have my initial design done by tomorrow. It's a steep goal, but I think I can do it.
<mmichelson>
It's made me negligent on the reviews this week as a result. I hope to get back into those more next week.
<mmichelson>
The rest of my work has been mostly downstream Red Hat stuff this week, so nothing to share here.
<mmichelson>
That's all from me. Who would like to go next?
<mmichelson>
...anyone?
<zhouhan>
hi
<amusil>
It doesn't seem that we have a huge audience, I wanted to open the debate about commiting in router pipeline
<dceara>
hi
<zhouhan>
I will go after you guys
<dceara>
I can go next, a short update.
<mmichelson>
amusil, yeah it seems like we're missing canonical people today.
<amusil>
I'll just leave it there for the record, we have a problem with conditional NAT and reply traffic that doesn't match the NAT
<dceara>
We had the technical A/V community meeting on Monday. Mostly about how to get (some more) BGP support in 25.03. I sent out an email after the meeting with the notes and recording. Also suggesting a new date for the next instance.
<dceara>
I'll wait until tomorrow afternoon before sending out a new invite.
<amusil>
The solution would be to commit traffic that isn't matches by any NAT, in more generic sense, it would be good to do something like we do in switch pipeline when there is stateful ACL or LB
<dceara>
Ah, sorry, amusil I went over you, please go ahead.
<amusil>
We are both guilty :D Yeah I'm mostly done, I would like to know any objections why we shouldn't commit basically any traffic in router pipeline when there is NAT or LB
<amusil>
That's it, thanks
<zhouhan>
amusil: there are SNAT and DNAT in router pipeline, so are you talking about always commit to both, or just the direction that's relavant?
<zhouhan>
amusil: I mean when using separate CT zones for them
<amusil>
Commiting to DNAT zone n ingress when there is any DNAT or LB, and commiting to SNAT zone in egress when there is any SNAT does that make sense?
<zhouhan>
amusil: sounds reasonable.
<zhouhan>
amusil: I will give some more thoughts on the side effects
<amusil>
Ack, thanks!
<zhouhan>
May I go next
<amusil>
I can prepare RFE patch for the follow up discussion
<dceara>
zhouhan, wouldn't this also address the issues you reported in the ovs-dev thread we have with Tim Rozet? About forwarding on ct.inv?
<zhouhan>
dceara: I was about to mention that. No, it seems different.
<dceara>
Hmm, ok, i need to think some more about it then.
<amusil>
But we would avoid ct.inv with commit in original direction
<amusil>
Because the reply would be always recognized
<amusil>
Anyway we can discuss that on the RFE patch
Nik- has joined #openvswitch
<mmichelson>
Sounds like a good idea. IMO, it's always easier to understand a proposal when it's written as code :)
<mmichelson>
OK, I think amusil was done. dceara did you have anything additional to add to your update?
<zhouhan>
dceara: Sorry I am confused after a second look at your message. The issue I reported a few weeks ago was about HW offload issue with asymmetric CT for SNAT/unSNAT. But what's related to ct.inv?
<dceara>
zhouhan, ah no, I got confused, I thought we were forwarding traffic on ct.inv in the HW offload issue you reported. But maybe it was ct.new?
<zhouhan>
dceara: right, it was ct.new
<dceara>
So, if we commit (because there are NATs in that case) shouldn't it fix that too?
<dceara>
But in any case, we can continue on-list, sorry mmichelson.
<dceara>
I only wanted to add one more thing to my report.
<zhouhan>
dceara: so one of the proposal (the one that was supported more by you and Tim) to always commit to both zones, but the concern was performance impact for recirc.
<dceara>
zhouhan, ack
<zhouhan>
dceara: I am still waiting for some performance evaluation on that with our HW offload team.
<dceara>
zhouhan, cool, it's nice that the ball is still rolling!
<amusil>
This would solve more problems at once which is nice
<amusil>
Let's see what the numbers look like
<zhouhan>
dceara: on the other hand, for your suggestion of integrating HW offload test with CI, I discussed with the team and received good support. Could you give me some pointers so that we can start the integration with patchwork?
<dceara>
I think we need to speak to Aaron Conole about the best way to do that. Ilya is probably a good person to ask.
<zhouhan>
dceara: got it, thanks. I will contact them
<dceara>
Thanks zhouhan
<zhouhan>
Other than this, I was debugging a RAFT scale issue during upgrade
<zhouhan>
I was upgrading from OVS3.1.2 to OVS3.3, which includes the last part of schema upgrade optimization that Ilya implemented, which includes file format change.
<zhouhan>
It seems that after schema conversion, the time spent on pushing changes (with conditional monitor) to all clients took much higher CPU with the new version.
<zhouhan>
But the scale I tested was also a little bit bigger than before. So I wasn't 100% sure if it is because of the code change or just the scale reached some tipping point.
<zhouhan>
imaximets: if you are here, do you remember anything off the top of your head between these two versions that could lead to higher load of the server?
<mmichelson>
Would it be possible to test with the same scale as before?
<zhouhan>
mmichelson: yes, I was about to do that. (the env was a bit messy, so need to take more time)
<zhouhan>
that's it from me :)
<dceara>
I had one more small thing:
<dceara>
I also posted a patch that adds the OVN (Linux Foundation) charter to the repo. That's because I realized it wasn't there and people sometimes miss the fact OVN is a LF project. Russell acked it and then I applied it. (OVS already had its own in the repo)
<dceara>
That's it on my side too.
<imaximets>
sorry, just joining... reading the history
<racosta_>
Can I go next?
<mmichelson>
racosta_, go ahead. That'll give imaximets time to catch up
<racosta_>
In the meantime, I saw that Numan's commented in another thread that he could accept Priyankar's commit with comments about the patch limitation. This other patch is an exact copy of my v0 and was rejected due to the limitation of not working with multiple chassis hosting the DGPs (The most common use case, in my opinion).
<racosta_>
Conntrack sync would definitely be the killer solution for this multiple DGPs use case but it is not simple to implement.
<racosta_>
Anyway, I think my patch solves Nutanix case too. So, can I suggest putting a config option to enable stateless NAT on the LB when the user wants to use it with multiple chassis for DGPs and leave the default with only the replicated flows for each additional port (v0 case)?
<mmichelson>
racosta_, yikes, it sounds like I need to sync with Numan about that.
jraju__ has joined #openvswitch
<racosta_>
Basically the default case would be without Stateles NAT but with config option to enable, would that be reasonable?
<mmichelson>
racosta_, I'll get together with Numan and find out why Priyankar's patch got an ack. It may be that he saw something I did not notice?
<racosta_>
Sure, no worries.
<mmichelson>
racosta_, I think an opt-in approach makes sense. That way, an admin has to make the choice to have their distributed NATs be stateless.
<racosta_>
I'm just trying to address all the use cases.
<mmichelson>
I also agree that distributed conntrack would be amazing :)
<amusil>
Well idea of distributed CT is there but we need to figure out how feasible it would be for scale before trying anything further
<mmichelson>
racosta_, I'm unlikely to get to v7 of your patch this week because I've created a tight deadline for myself on a design document. But I can put it on my radar for next week
<mmichelson>
RH has a face-to-face event in Brno next week, and several of the people in this meeting will be there. I, however, will not be. So that may free me up for more reviews and other things.
<racosta_>
No rush, I will work on a new version with an opt-in approach.
<mmichelson>
ack, sounds good.
<mmichelson>
Anything else from you racosta_ or were you done with your update?
<racosta_>
No, that's it on my side too. Thanks
<_lore_>
can I go next?
<_lore_>
quite fast
<mmichelson>
_lore_, go right ahead
<_lore_>
this week I worked adding missing bits (IPv6 + tests) for the Nexthop CT flush series, I will post rfc v2 upstream so we can discuss on it
ihrachys has quit [Ping timeout: 252 seconds]
<_lore_>
+ I posted a fix for IPAM
<_lore_>
trivial patch
ihrachys has joined #openvswitch
<_lore_>
moreover I would like to start looking at FRR and BFD integration but I guess we need to align with canonical folks for it
<_lore_>
that's all from my side
<mmichelson>
Thanks _lore_ .
<mmichelson>
Anyone else?
<imaximets>
May I?
<mmichelson>
imaximets, go right ahead
<imaximets>
First, let me answer zhouhan's question:
<imaximets>
I'm not aware of anything that would increase CPU load between 3.1.2 and 3.3.0, if anything, I'd expect the load to go down with condition changes being processed incrementally now.
<imaximets>
So, I'm not sure what is going on in your setup. Would definitely like to see the results for the same scale.
<zhouhan>
imaximets: good to know. thanks!
<zhouhan>
imaximets: just recalled one of the feature was cooperative multitasking, but seems shouldn't have such impact
<imaximets>
Other than that I'm just recovering from my PTO. :) Also looked at one scalability problem reported by OpenShift folks and postead a patch for northd to stop monitoring most of the Nb external ids.
<imaximets>
zhouhan, yeah, coop multitasking should not cause much trouble.
<imaximets>
And that's all from my side.
<mmichelson>
Thanks imaximets
<zhouhan>
imaximets: the northd optimization result looks really impressive. thanks!
<mmichelson>
Any further updates from anyone?
<mmichelson>
Oh, I just remembered something I had wanted to ask zhouhan
<mmichelson>
zhouhan, during our internal OVN meeting today, we were discussing about how user-defined networks in OpenShift are going to result in more logical switches and logical routers being created and destroyed in ovn-kubernetes deployments. So we have been planning tasks to incrementally process logical switch and logical router creation/deletion.
<mmichelson>
It was brought up that in the past, you had cautioned against doing this. Was it simply because the scenario was rare, and so the effort would be wasted? Or was there a different reason for not wanting I-P for switch and router creation/deletion?
<zhouhan>
It was because the scenario was rare and the I-P is difficult :)
<mmichelson>
zhouhan, ack, got it
<zhouhan>
It is just getting more and more complex, and every time we add I-P for something it was more or less painful :)
<mmichelson>
It sure is!
<mmichelson>
Last chance for anyone else to add an update/ask questions
<mmichelson>
OK, I think we're done! Thank you everyone. Have a nice day.
<mmichelson>
Bye!
<dceara>
Thanks, bye!
<imaximets>
Thanks! Bye.
mmichelson has quit [Quit: Leaving]
<zhouhan>
thanks, bye
dceara has quit [Quit: Leaving]
<amusil>
Thanks, bye
<_lore_>
bye
amusil has quit [Quit: Client closed]
<racosta_>
bye
jraju__ has quit [Ping timeout: 252 seconds]
ihrachys has quit [Ping timeout: 252 seconds]
ihrachys has joined #openvswitch
jsn has joined #openvswitch
zhouhan has quit [Ping timeout: 256 seconds]
kuraudo has quit [Read error: Connection reset by peer]
ihrachys has quit [Ping timeout: 260 seconds]
ihrachys has joined #openvswitch
unixpro1970 has quit [Remote host closed the connection]
unixpro1970 has joined #openvswitch
ihrachys has quit [Ping timeout: 245 seconds]
Nik- has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
donhw has quit [Read error: Connection reset by peer]
donhw has joined #openvswitch
froyo__ has quit [Ping timeout: 252 seconds]
ihrachys has joined #openvswitch
ihrachys has quit [Ping timeout: 260 seconds]
racosta_ has quit [Remote host closed the connection]