On 6/13/23 15:55, Vašek Šraier wrote:
> Hi,
>
> On 2023-06-12 18:40, Ilya Maximets wrote:
>> Flushing datapath flows underneath running ovs-vswitchd process
>> may cause all kind of weird behaviour. So, the del-flows as well as
>> most of the other ovs-dpctl commands should not be used under normal
>> circumstances. Here is what the man page says:
>>
>> """
>> Do not use commands to add or remove or modify datapath flows if
>> ovs-vswitchd is running because it interferes with ovs-vswitchd's own
>> datapath flow management. Use ovs-ofctl(8), instead, to work with
>> OpenFlow flow entries.
>> """
>
>
> Ok. I didn't notice this paragraph. Thank you for pointing that out.
>
>
> Could you please explain in more detail why flushing the datapath flows
> would cause these problems? Because some of my assumptions about OVS
> must wrong and I don't know which. Just a link to relevant source code
> could probably help me a lot.
>
> My current understanding is that the datapath flows are always installed
> as a reaction to an upcall. There are no statically installed datapath
> flows. Also, the revalidator threads always dump the real content of the
> datapath and then check every dumped flow if it should be deleted. It
> does not have to keep track of the flows in between runs.
>
> So, assuming the above, when I flush the flows, all packets will
> generate upcalls and the necessary rules will be immediately installed
> again, business as usual.
See the following code path in ofproto/ofproto-dpif-upcall.c:
handle_upcalls()
--> ukey_install()
--> ukey_install__()
--> try_ukey_replace()
Only if ukey_install() succeeds, the flow will be installed to the
datapath. In your case the try_ukey_replace() will return false, because
we have the exactly same ukey. And this result will float up. Actions
will be executed, but the flow will not be installed.
>
> I'd guess, that if ovs-vswitchd kept a synchronized copy of the kernel
> flow table in userspace and we'd desync it by flushing the kernel table,
> the next revalidator run would fix the problem and everything would
> behave normally again. (I didn't find any code in revalidator, that
> would do this though). What's the catch?
Revalidators revalidate ukeys for flows that they dump from the datapath.
I.e. they iterate over dumped flows, not over all the ukeys during the
main phase. Also, these ukeys are getting their stats updated, because
there is still traffic going through them via upcalls, so they will not
be revalidated, so they are not getting cleaned up during the
revalidator_sweep__() phase.
Also the dump is not a reliable source of information, because it happens
concurrently from multiple threads and also while handlers are installing
new flows. So, if the flow is not in the dump, it doesn't generally mean
that it's not in the datapath.
Best regards, Ilya Maximets.
>
>
> On 6/11/23 14:20, Vašek Šraier via discuss wrote:
>> Test environment
>> ================
>>
>> 3 node Kubernetes cluster using OVN-Kubernetes, Docker and Fedora 38.
>
> I've managed to reproduce the same behavior on a single system with just
> OVS and a single network namespace. No explicit OpenFlow rules are needed.
>
> I guess this is not unexpected, but I wanted to confirm it regardless. :)
>
>
> Best,
> Vašek
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
