On Tue, May 28, 2013 at 03:56:58PM -0700, Gurucharan Shetty wrote: > 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.
That sounds reasonable. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
