numans has quit [Remote host closed the connection]
ihrachys has joined #openvswitch
tpires has quit [Ping timeout: 245 seconds]
ChmEarl has quit [Quit: Leaving]
terdei has quit [Ping timeout: 252 seconds]
terdei has joined #openvswitch
kuraudo has joined #openvswitch
froyo has joined #openvswitch
elvira1 has joined #openvswitch
vlrpl has joined #openvswitch
imaximets has quit [Remote host closed the connection]
tpires has joined #openvswitch
imaximets has joined #openvswitch
imaximets has quit [Remote host closed the connection]
imaximets has joined #openvswitch
kuraudo has quit [Remote host closed the connection]
kuraudo has joined #openvswitch
hamburgler has quit [*.net *.split]
mnasiadka has quit [*.net *.split]
mnasiadka has joined #openvswitch
hamburgler has joined #openvswitch
dceara has joined #openvswitch
froyo has quit [Ping timeout: 246 seconds]
dceara has quit [Ping timeout: 246 seconds]
dceara has joined #openvswitch
roriorden has joined #openvswitch
imaximets has quit [Changing host]
imaximets has joined #openvswitch
amusil has joined #openvswitch
mmichelson has joined #openvswitch
mkalcok has joined #openvswitch
zhouhan has joined #openvswitch
<mmichelson>
Hi everyone. It's time to begin the weekly OVN developers' meeting.
<mkalcok>
o/ hello
<fnordahl>
o/
<amusil>
Hi
<zhouhan>
hi
<mmichelson>
I can give the fist update.
<mmichelson>
Tomorrow is soft freeze for ovn 25.03. If you have feature patches that you want included in ovn 25.03, then please submit them by the end of the day tomorrow.
<mmichelson>
We've been doing a fantastic job of getting reviews done before the soft freeze, so great job to everyone on that.
<mmichelson>
I've been working on getting a new version of the established sessions ACL series up. I realized that I couldn't find 16 bits of free register space to use for storing an ACL ID.
<mmichelson>
amusil submitted a patch that addressed this problem and freed up 48 contiguous bits of register space, which is more than what I needed. So thanks Ales for that.
<mmichelson>
I merged that patch just before this meeting started.
<mmichelson>
I've also been reviewing other submissions on patchwork.
<mmichelson>
I plan to get the latest established sessions series posted before the end of the day.
<mmichelson>
That is all from me. Who would like to give the next update?
<mkalcok>
I could give mine
<mmichelson>
go for it mkalcok
<mkalcok>
I've posted a minor bugfix to OVS, and addressed review comments from Ilya and Eelco, thanks for the review and sorry for the sloppy first version.
<mkalcok>
It allows OVS to parse system routes even if they don't have next-hop specified
<imaximets>
mkalcok, no problem, thanks for the fixes!
<mkalcok>
On the OVN side I posted a relatively short series that adds abbility to advertise NAT and LB VIPs.
<mkalcok>
I posted this as an RFC, because it's based on two in-flight patch series by Felix that provide general Route Advertising mechanisms.
<mkalcok>
Would this be enough for it to be considered as "posted before soft-freeze"?
<mmichelson>
mkalcok, yes. But like with any patch, getting it posted before the soft freeze is not a guarantee it will be accepted.
<mkalcok>
I assume that there are going to be some minor changes needed (mainly to tests) based on new versions of Felixes patches, but I'll tend to that
<mkalcok>
Noted, thanks mmichelson
<mkalcok>
That's all from my side.
<mmichelson>
Thanks mkalcok. Who would like to go next?
<fnordahl>
I have an update
<imaximets>
fnordahl, I guess, you can go ahead. :)
<fnordahl>
Addressed coverity report on the OVS route-table changes, and while being in the vigilant mode, closed a couple of additional potential issues.
<fnordahl>
Doing end to end review of the whole BGP epic, and investigating the feasability of supporting announcement of resources indirectly connected to a GW router.
<fnordahl>
Intend to post something before soft freeze if I find that to be the case.
<fnordahl>
(If soft freeze enforcement delays until over the WE, I have a window of opportunity to poke at the IPv6 PD stuff on Saturday).
<fnordahl>
That's it for me.
<mmichelson>
Thanks fnordahl. Who's next?
<imaximets>
May I?
<mmichelson>
go right ahead imaximets
<imaximets>
Together with Eelco I reviewed and applied the route-table fixes from fnordahl. Thanks!
<imaximets>
And I worked on a spine-leaf
<imaximets>
logical switch topology for OVN.
<imaximets>
Patches are ready, just need to write some commit messages and post.
<imaximets>
The main part was simple, ovn-ic support got slightly more difficult, but also not a big deal.
<imaximets>
That's it from me.
<zhouhan>
imaximets: is it for scalability?
<imaximets>
Yes. To be able to have a sngle L2 domain across multiple AZs without adding remote ports for every port on the switch.
<mmichelson>
I'm looking forward to those patches when they're posted.
<mmichelson>
Based on the past few reports, I'm *very* glad we have gotten a jump on reviews this time, since it sounds like we can expect a few more new patches before tomorrow.
<zhouhan>
imaximets: got it, thanks.
<imaximets>
zhouhan, in short, a transit spine switch and simple node logical switches linked to a spine with ports with "unknown" addresses.
<imaximets>
Like a localnet, but without localnet. :)
<mmichelson>
Who wants to go next?
<zhouhan>
imaximets: so this is purposely for the L2 requirement?
<zhouhan>
My oneline update: I was debugging a multi-NIC/encap related bug, and will post the fix soon.
<dceara>
I can go next if that's OK. (Sorry for joining late)
<mmichelson>
go for it dceara
* mmichelson
steps away for a minute
<imaximets>
zhouhan, mostly for L2, yes. Since it's a connection between switches. But I guess, there may be some creative uses.
<imaximets>
dceara, sorry, go ahead.
<dceara>
imaximets, no problem
<dceara>
I've been reviewing patches, I finally managed to have a look at the active-active series from Felix. But I have some concerns about that one. I posted them on list.
<dceara>
And that's about it. Planning to continue with reviews tomorrow too.
* mmichelson
is back
<dceara>
Oh and I'm really interested in fnordahl investigation about "announcement of resources indirectly connected to a GW router".
<dceara>
I think that's a very interesting use case for ovn-kubernetes too.
<dceara>
That's it on my side, thanks.
<mmichelson>
Thanks dceara
<fnordahl>
dceara: cool stuff, thanks for reviews btw, I'll chime in once we get into soft-freeze
<mmichelson>
Does anyone else wish to give an update?
<amusil>
I can
<mmichelson>
amusil, go ahead
<amusil>
Posted the register consolidation that mmichelson mentioned, I'm also reworking the commit-all to be router option instead
<amusil>
We have found out that it has impact up to 10% for regular traffic patterns, so will leave it up to CMS when they want to take the hit by enabling it
<amusil>
Once I sort out some testing it should be ready to go
<zhouhan>
amusil: is the 10% with kernel datapath?
<amusil>
That's it, thanks
<amusil>
zhouhan Yes with kernel dp
<zhouhan>
amusil: thanks! If using an option, it means we will keep both branches of code. Would that make the code even more complex?
<zhouhan>
amusil: I remember one big motivation was to simplify the code
<amusil>
No that much fortunately, there are some corner cases that will remain handled as before and will be removed when the option is enabled
<zhouhan>
amusil: ok, looking forward to your patch, but we will (hopefully) do some more test with HW offload with your current patch
<dceara>
In general: knobs-- but in this case the performance hit was not really acceptable by our users (and I suspect upstream wouldn't be too happy either).
<dceara>
s/by/for/
<zhouhan>
dceara: but it also means the original bug related to the SNAT (in the k8s use case) will not be fixed when the option is disabled
<amusil>
Correct
<dceara>
zhouhan, that is correct. "Fortunately" the users were OK with the performance hit in the case when conditional SNAT is used.
<amusil>
However ovn-k is ok with enabling it for the UDN
elvira1 has quit [Ping timeout: 246 seconds]
<zhouhan>
amusil: ovn-k has different users, and I guess it is hard to say for the users whether they accept the 10% performance drop
<fnordahl>
fwiw, I hear more complaints about some axis of connectivity not working than performance, but this is anectdotal
<dceara>
zhouhan, fair point, I meant Red Hat users.
<zhouhan>
I mean, even for Red Hat users, different users may have different requirement, right? (I am not in the position to judge, but just curious how this would be taken care :) )
elvira has joined #openvswitch
<dceara>
zhouhan, I'm afraid at this point the only thing we can do is allow users to opt-in - pointing out any potential performance issues they might face.
<dceara>
Of course, if we could simplify the pipeline and avoid the extra recirculation we should do that. But I don't think we found a solution in that direction.
<zhouhan>
I forgot what are the other issues the commit-all was trying to fix. At least the ovn-k SNAT issue could be solved by reverting the skip-snat flow change, while adding constraints in ovn-k for the port ranges.
<dceara>
There was another report with conditional SNAT that was breaking other traffic patterns.