On Mon, May 20, 2013 at 11:00 AM, Ben Pfaff <b...@nicira.com> wrote: > 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 <gshe...@nicira.com> > > 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. > After spending some time on this, I decided to reduce the scope of the implementation. I am introducing a variable called "other_config:flow-restore-wait" which when set to true, before vswitchd starts, makes vswitchd not receive any packets from the datapath, or flush the datapath flows or expire them. Once the variable is set as "false" (or removed) in the database, vswitchd resumes normal operation. Setting/unsetting this variable after that has no effect. I think this reduced scope solves the issue that it originally was meant to solve. A more general purpose implementation of hands-off datapath anytime (not just during the startup), would mean that I would have to go through multiple columns in the database clearing states of different columns which would make it a little more complicated. I will send a V2.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev