Hi Ben:
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?
Thanks
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/
> >
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
