[ovs-dev] dev Digest, Vol 46, Issue 129

Jing Ai ai_jing2000 at hotmail.com
Wed May 22 20:52:30 UTC 2013



> 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 <gshetty at 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

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130522/4497f532/attachment-0003.html>


More information about the dev mailing list