[ovs-dev] [PATCH v2] ovn-controller: Reset flow processing after (re)connection to switch

Ryan Moats rmoats at us.ibm.com
Thu Aug 11 14:15:13 UTC 2016


"dev" <dev-bounces at openvswitch.org> wrote on 08/11/2016 07:21:39 AM:

> From: Numan Siddique <nusiddiq at redhat.com>
> To: ovs dev <dev at openvswitch.org>
> Date: 08/11/2016 07:21 AM
> Subject: [ovs-dev] [PATCH v2] ovn-controller: Reset flow processing
> after (re)connection to switch
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> When ovn-controller reconnects to the ovs-vswitchd, it deletes all the
> OF flows in the switch. It doesn't install the flows again, leaving
> the datapath broken unless ovn-controller is restarted or ovn-northd
> updates the SB DB.
>
> The reason for this is
>   - lflow_reset_processing() is not called after the reconnection
>   - the hmap "installed_flows" is not cleared, because of which
>     ofctrl_put skips adding the flows to the switch.
>
> This patch fixes the issue and also adds a test case to test
> this scenario.
>
> Signed-off-by: Numan Siddique <nusiddiq at redhat.com>
> ---

This all looks does what it promises, so let's get the immediate
out of the way:

Acked-by: Ryan Moats <rmoats at us.ibm.com>

Having said that, I'm still concerned about what happens in the
kernel during an ovs-vswitchd restart...

I *think* everything will be fine for active connections whose
flow rules are still in the kernel, but there will be a momentary
loss of connectivity for those connections that require an upcall
to access the flows known to vswitchd.

If the above is right, then I'm willing to accept that, but it
begs two questions:

(1) is this something that is too complex for a unit test case?

(2) if it isn't too complex, how would one code such a unit
    test case?




More information about the dev mailing list