On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote: > Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote: > >On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote: > >> Yes, it is the same. > > > >FWIW I also see what Amritha and Alex are describing here, for cls_bpf > >there are no DESTROYs coming on rmmod or qdisc del. There is a DESTROY > >if I manually remove the filter (or if an ADD with skip_sw fails). > > Is this different to the original behaviour? Just for cls_bpf?
For cls_bpf the callbacks used to be 100% symmetrical, i.e. destroy would always be guaranteed if add succeeded (regardless of state of skip_* flags). I haven't checked cls_flower on the nfp because it implodes on add already... I hear the fix is simple so I can check, if that helps. Although from quick code inspection it seems fl_hw_destroy_filter() was always invoked before fl_destroy_filter(), so it looks like since flower doesn't track which filters were offloaded successfully it may send destroy events for filter drivers don't hold, but destroy should always be guaranteed there too.
