On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote:

Sat, Oct 28, 2017 at 02:52:00AM CEST, kubakici@wp.pl wrote:

quoted

On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote:  

quoted

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.