> 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.)
Agree. Also you need not to garbage the dpif's ports in open_dpif_backer()
right after dpif_flow_flush(). Otherwise, even if kernel flows are preserved,
the netdevs behind the port number are gone.
>
> 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.
How about detach_dpif? Basically, we do not want to control the fast datapath
as usual until finishing restoring flows explicitly.
Best,Jing
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
