kuraudo has quit [Remote host closed the connection]
kuraudo has joined #openvswitch
David__ has joined #openvswitch
arif-ali has quit [Ping timeout: 256 seconds]
arif-ali has joined #openvswitch
dceara has joined #openvswitch
ChmEarl has joined #openvswitch
felixhuettner has joined #openvswitch
felixhuettner has quit [Client Quit]
mmichelson has joined #openvswitch
fnordahl has joined #openvswitch
mkalcok has joined #openvswitch
<mmichelson>
Hi everyone, it's time to begin the weekly OVN developers' meeting.
<mkalcok>
o/
<fnordahl>
\o
zhouhan has joined #openvswitch
<mmichelson>
I can go very quickly with a one-liner: Working on a customer issue with a weird setup. Otherwise working on multiple downstream things.
<mmichelson>
Who wants to go next?
<mkalcok>
I wouldn't mind jumping in.
<mmichelson>
mkalcok, go for it!
<mkalcok>
Pretty much the same as last week. In case we have amusil around, I'd like to hear his opinion on the solution for unnecessary DNAT_AND_SNAT conntract entries
<mmichelson>
Thanks mkalcok. I think amusil is out today :(
imaximets_ is now known as imaximets
<mmichelson>
Who's next?
<mkalcok>
I'll get him some day :D
<fnordahl>
I have a quick one
<mmichelson>
fnordahl, great, let's hear it!
<fnordahl>
Mostly downstream stuff.
<fnordahl>
I do have a question for zhouhan, from the top of your mind, do you know if match on ip.is_frag would cause any issues for hardware offload?
<fnordahl>
If not on top of mind, I'll figure it out
<mmichelson>
OK, I guess zhouhan can answer that if he's able to. But in the meantime, do we have any other people that want to give updates?
<mmichelson>
I guess it's a short one today :)
<imaximets>
My one-liner: Not much this week, did some reviews, reported an issue with the static mac binding updates that is now fixed.
<zhouhan>
fnordahl: sorry, I don't remember
<mmichelson>
imaximets, thanks!
<zhouhan>
fnordahl: let me check later
<mmichelson>
Final call for updates from anyone else.
<zhouhan>
May I
<mmichelson>
zhouhan, go for it
<zhouhan>
I continued working on flow-based tunneling, because I think it is still needed
<zhouhan>
imaximets: I had a quick test for ovs, when there are ~7000 ports, adding a new one would take 10+ seconds, and CPU is hot
<imaximets>
Did you profile where the time is spent?
<zhouhan>
In a use case with multiple encap IPs per nodes, e.g. 8 IPs, and with just 1000 nodes, there will be 64k tunnel ports on OVS, which will be crazy
<imaximets>
Is that a common configuration to have 8 encap IPs?
<zhouhan>
imaximets: In that environment, yes
<imaximets>
Sounds a little excessive. :)
<zhouhan>
imaximets: profile shows something in ofproto_run->update_port->update_mtu, but I haven't checked in more details
<zhouhan>
imaximets: I will see if there is a quick fix for the OVS performance, but I am still worried about that many tunnel ports in one OVS
<zhouhan>
That's it from me
<moloings>
Onliner, Working on route implementation for transit router and reviews, Datapath and Portbinding tunnel keys for TR across AZs working
<mmichelson>
moloings and zhouhan thanks!
<mmichelson>
Anyone else?
<imaximets>
zhouhan, tunnel ports do not exist in the kernel, they are purely an abstraction in userspace, FWIW.
<imaximets>
* one port exists in the kernel
<imaximets>
fnordahl, there can be some quirks, for example, we do not support offloading of ipv6 fragments if you match on fragment bits.
* imaximets
has no further comments
<fnordahl>
ty imaximets zhouhan
<zhouhan>
imaximets: so you mean they are merely OVSDB configurations, and it shouldn't be a big deal of OVSDB to handle 64k ports?
<imaximets>
Yes. There is no incremental processing in ovs-vswitchd, but it shouldn't be that long to preocess. If it is that long, then we should look and see why.
<zhouhan>
imaximets: ok, let's try to optimize that if it is just a performance bug. But at the same time do you see any side-effect of flow-based tunneling?
<imaximets>
Should be fine, beside non-working BFD and IPsec. Not sure what else may be broken.
<zhouhan>
imaximets: except that BFD and IPSec will be challenging, but in the environment that requires that many tunnel ports we don't require these two features :)
<zhouhan>
imaximets: ok, thanks for the information. At least we have two potential solutions :D
<mmichelson>
OK, thanks for the discussion everyone. Have a good day!
<zhouhan>
Have a good day
mmichelson has quit [Quit: Leaving]
<moloings>
Bye!
moloings has quit [Quit: WeeChat 4.6.3]
<imaximets>
Thanks! Bye.
<fnordahl>
\o cheers
<zhouhan>
fnordahl: I just checked OVS code and at least is_frag can be offloaded to TC, but I never tried this with HW
<zhouhan>
fnordahl: but for IPv6 if nw_proto is IPPROTO_FRAGMENT the offload to TC is not supported even by OVS
hamburgler has quit [Remote host closed the connection]
donhw has quit [Ping timeout: 245 seconds]
donhw has joined #openvswitch
hamburgler has joined #openvswitch
tabakhase has quit [Server closed connection]
tabakhase has joined #openvswitch
zhouhan has quit [Ping timeout: 250 seconds]
hamburgler has quit [Remote host closed the connection]
tpires has joined #openvswitch
kuraudo has quit [Quit: kuraudo]
dceara has quit [Quit: Leaving]
imaximets has quit [Remote host closed the connection]