psilva has quit [Remote host closed the connection]
psilva has joined #openvswitch
tpires has joined #openvswitch
psilva has quit [Ping timeout: 248 seconds]
_whitelogger has joined #openvswitch
froyo_ has joined #openvswitch
froyo_ has quit [Remote host closed the connection]
nusiddiq__ has joined #openvswitch
dceara has joined #openvswitch
nusiddiq__ is now known as numans
Guest62 has joined #openvswitch
ChmEarl has joined #openvswitch
donhw has quit [Ping timeout: 252 seconds]
tpires has quit [Ping timeout: 260 seconds]
moloings has joined #openvswitch
donhw has joined #openvswitch
numans has quit [Ping timeout: 272 seconds]
Guest62 has quit [Quit: Client closed]
<dceara>
Hi everyone! It's time for the weekly OVN developers' meeting. Mark is off today so I'll try to lead the meeting.
<_lore_>
hi all
<dceara>
I can start with my short update.
imaximets__ has quit [Changing host]
imaximets__ has joined #openvswitch
imaximets__ is now known as imaximets
<dceara>
I'm working on some of the bits required for adding EVPN support to OVN dynamic routing. Slowly progressing.
zhouhan has joined #openvswitch
<dceara>
Aside from that I've reviewed (some) patches this week and hopefully can review some more next week.
<dceara>
A couple of announcements:
<dceara>
1. The technical community meeting (A/V) is happening next week, Monday, June 23rd at 3PM UTC (also announced on-list)
<dceara>
2. Soft freeze is approaching (still quite far) but I wanted to remind folks. It's scheduled for July 25th.
<fnordahl>
o/
<dceara>
(soft freeze for 25.09)
<dceara>
That's it on my side. Who else would like to share?
<imaximets>
May I?
<dceara>
Sure, imaximets, go ahead.
<imaximets>
Not much from my side, been traveling for devconf last week and catching up on reviews this week.
<imaximets>
Since the soft freeze is mentioned, OVS one will be on July 1st, IIRC.
<imaximets>
That's all from me.
<_lore_>
can I go next? quite fast
<dceara>
Thanks, imaximets! _lore_, sure, go ahead.
<_lore_>
I resumed some work on I-P for northd, I was resuming the work numan did for ls incremetal processing
<_lore_>
I am starting from his patches, keeping his SoB
<_lore_>
that's all from my side
<dceara>
Thanks, _lore_, it would be nice to have incremental processing support for switches too!
<dceara>
Who wants to go next?
<zhouhan>
I can go next
<zhouhan>
I have been working on fixing the new HW offload issue introduced by "Allow fragmented traffic through LB"
<zhouhan>
I firstly looked at whether I can optimize OVS but it seems challenging.
<zhouhan>
Then I found a way to solve it by adjusting flow priorities in OVN. So I am working on a formal patch with this approach.
<zhouhan>
That's it from me
<dceara>
Thanks, zhouhan!
<dceara>
zhouhan, that one was a bit surprising because the commit log of the offending patch says "this shouldn't cause any HWOL issues because the match is adjusted only for ct.new packets that cannot be offloaded anyway."
<zhouhan>
If we have time, I want to ask imaximets for more detailed questions on OVS classifier
<dceara>
zhouhan, I think that should be fine, if imaximets has time. But let's see if anyone else has other stuff to report first?
<zhouhan>
dceara: yes, I think that's a misunderstanding of how OVS is generating megaflows
<fnordahl>
oneliner for me, temperature could be lower, and the clock could be slower, mostly downstream stuff, participated in Neutron spec discussions and reading up on Numan's proposal for a distributed pr-controller, as it's relevant for the BGP stuff single NIC operated by OVS use case
<dceara>
fnordahl, thanks for your update! It seems there are more and more possible use cases for Numan's pr-controller, that's nice to see!
<dceara>
Is there anyone else left who didn't share an update and wishes to?
<dceara>
OK, zhouhan, I guess we can continue with the OVS classifier discussion.
<imaximets>
sure
<zhouhan>
OVS generates megaflows not just according to what's matched in openflow tables, but also what's not matched. In this case, when a packet of an established connections comes, although it doesn't match the flow that has "ct_state=new && ct_nw_proto=xxx", just because it is examined against the rule, the megaflow unwildcards the ct_nw_proto field as
<zhouhan>
exact match.
<imaximets>
Yes, if it's lower or the same prio.
<zhouhan>
In theory OVS could be optimized so that when ct_state is not matched, then don't consider other ct fields of the same flow.
<zhouhan>
imaximets: is this considered before?
<dceara>
Ah, right, we got taken by surprise by this before and had to update ovn flow priorities in other instances.
<imaximets>
It's complicated. The classifier has a few stages and multiple fileds are located within the same stage for matching.
<imaximets>
If the stage doesn't match, then all fields from the stge are unwildcarded.
<imaximets>
The optimization for this is prefix trees (tries) that can wildcard some of that back.
<imaximets>
Increaing number of stages is very complicated.
<zhouhan>
imaximets: I see that OVS classifier has a "segment" concept that has some sort of optimizations around such, but the segments are hardcoded
<imaximets>
Yes, segments == stages
<zhouhan>
imaximets: I tried to move ct_nw_proto to a separate stage from ct_state, but just moving the fields from the structure breaks tests
<zhouhan>
imaximets: not sure if this is a path worth trying
<imaximets>
You also must consider dependencies between segments. It's very complicated. I'd suggest changing the segments only as a last resort.
<zhouhan>
imaximets: I see. Thanks for the info!
<imaximets>
Np.
<zhouhan>
I will working on the OVN flow priorities for now
<zhouhan>
That's all I wanted to ask :)
<dceara>
zhouhan, I think this is a good moment for me to bring up my broken record.. :)
<dceara>
Is there maybe any chance we could get some sort of HWOL CI reports upstream?
<dceara>
Maybe not on a per-patch basis but periodically?
<zhouhan>
dceara: oh, sorry for the delay. We actually are running HWOL CI against upstream commits and this issue was detected by that CI
<zhouhan>
dceara: we just can't run against unmerged patches for security reasons. Still need to figure out how to achieve that but it is lower priority
tpires has joined #openvswitch
<zhouhan>
dceara: for this issue, the CI system also was broken for a while so that's why the detection was also a little delayed
<dceara>
zhouhan, I see, that's good news. Maybe we don't need reports on unmerged patches (we don't run ovn-heater tests on unmerged patches either).
<dceara>
zhouhan, ack, would it make sense to report failures on-list (automatically?)?
<fnordahl>
++
<zhouhan>
dceara: yes we will work on an official account so that we can integrate with the ML
donhw has quit [Read error: Connection reset by peer]
<dceara>
zhouhan, awesome, thanks a lot!
<zhouhan>
dceara: np
donhw has joined #openvswitch
<dceara>
OK, one last call for people who might have joined late, anyone else who wishes to share an OVN update?
<dceara>
I guess that's it for today, thanks everyone! Have a nice rest of your day!