> > > > Hi > > > > Thanks for your review. I test it with openflow, It works fine because > > > > the *revalidator > > > > will clean up the flows(which may be offloaded). > > > > > In case above scenario leaves ufids in OVS that cannot be removed, > > > > > I'd suggest > > > > > reverting of the previous patch that allowed offloading via add-flow > > > > > since this > > > > > is effectively a memory leak and even debugging commands should not > > > > > produce > > > > > a memory leak. > > > > yes, we can revert the previous patch. But I think the command is > > > > useful for us to > > > > debug offload(rte flow offload and tc offload), and test the offload > > > > function. > > > > For this issue, can we use this little patch to fix it ? or other > > > > better way ? > > > > > > I am confused. Which little patch? > > Hi Simon > > This patch [1]: > > [1] - > > http://patchwork.ozlabs.org/project/openvswitch/patch/20200611103635.53367-1-xiangxia.m....@gmail.com/ > > > > If we revert the patch which commit id is > > e61984e781e6c7d621568428788cb87c11be8f1f > > and we can't debug or install the flows with "ovs-app dpctl/add-flow", > > for tc offload. > > I think that tools are useful for us. > Hi Simon, Ilya > Do we have plan to apply this patch, or drop this patch ?
My understanding from reading the discussion is that using ovs-appctl dpclt/add-flow is just for debugging purposes. When using the right way, the ovs-ofctl add-flow, there is no such problem. I don't have any strong opinion on drop or apply. William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
