[ovs-dev] Re：Re：[PATCH 2/2] ofproto: Do not delete datapath flows on exit by default
txfh2007 at aliyun.com
Wed Mar 25 09:49:07 UTC 2020
I have two questions about this function:
Firstly, for some SDN controller (OVN etc.), the arp request is handled by userspace, that means: When ovs-vswitchd exits, the remaining traffic should only keep for about 30s as for most linux kernel, every 30s it should send an arp request out(for partner's mac addr), and when there is no reply, the traffic would breakdown. So how could we solve this problem if the upgrading should last for several minutes?
Secondly, for DPDK datapath, it doesn't work, is it possible that keep the netdev datapath's flows when ovs-vsiwtchd exits?
Re: Re：[PATCH 2/2] ofproto: Do not delete datapath flows on exit by default
I applied this to master.
On Sat, Feb 29, 2020 at 10:59:37AM -0800, Ben Pfaff wrote:
> Thanks for testing.
> I think that the "destroy" call should be outside the braces; the simap
> does not "own" the ports, it's just an string-to-integer map that needs
> to get destroyed along with the ofproto.
> On Sat, Feb 29, 2020 at 10:26:42AM +0800, txfh2007 wrote:
> > Hi Ben:
> > I have tried, this patch works! Thank you!
> > One question: should "simap_destroy(&backer->tnl_backers)" be within the close brace ?
> > Timo
> > Re: [PATCH 2/2] ofproto: Do not delete datapath flows on exit by default
> > On Wed, Feb 26, 2020 at 04:40:25PM +0800, txfh2007 wrote:
> > > Hi Ben:
> > >
> > > I have read your patch about "not delete datapath flow when daemon exit". I think this patch is really important, It can be used during upgrading without effecting existing traffic. I have test in my env, and found it works! Thanks a lot !
> > > But I have a question about tunnel traffic: I have found if there're vxlan traffic across compute nodes, when daemon exit, the traffic would breakdown. The reason is during "close_dpif_backer" we would delete tunnel port in datapath, so even if the flows are not delete , but as the tunnel port is deleted , flow action turns to be "drop". So i write this mail to ask if we can add a flag to control this behavior ?
> > Please test this patch: https://patchwork.ozlabs.org/patch/1246701/
More information about the dev