On Mon, May 20, 2013 at 06:53:14AM +0000, Gurucharan Shetty wrote: > This commit provides an option to enable or disable packet processing > coming from the datapath. > > This option is useful during Open vSwitch upgrades. Typically we want > to restart openvswitch, add the openflow flows and then start packet > processing. The next commit will use these commands in Open vSwitch > startup scripts. > > Bug #16086. > Signed-off-by: Gurucharan Shetty <[email protected]>
I think that this is the right direction but I think that it is not quite enough. First, I think that we should not do the initial dpif_flow_flush() in open_dpif_backer() if recv_set_enable is false. (Probably, we should do it when recv_set_enable is changed to true.) I think that recv_set_enable should affect other work done by ofproto-dpif also. For example, I think that when packet processing is disabled, we should not do flow expiration processing (we should skip calling expire()) because we do not know what flows are in the datapath and should not try to match them up with our internal model. Looking at type_run() and run(), I see some other cases where we should also skip processing. Once we take this into account, I think that the documentation needs some clarification. It's not really a matter of whether we receive packets from the datapath. It's more about whether OVS gets involved in datapath packet processing at all. Turning off recv_set_enable is kind of a "hands off the datapath" flag, with the goal being to allow the flows set up by a previous run of ovs-vswitchd (or even a different switch I guess) to live on unchanged until the new instance is really ready to process packets. I don't know of a good term or short description for this, but I think we should spend some time coming up with a good name. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
