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: >> >>> 2. Deleting the ingress qdisc fails to remove filters added in >> >>> HW. Filters in SW gets deleted. >> >>> >> >>> We haven’t exactly root-caused this, the changes being extensive, but >> >>> our guess is again something wrong with the offload check or similar >> >>> while unregistering the block callback (tcf_block_cb_unregister) and >> >>> further to the classifier (CLS_U32/CLS_FLOWER etc.) with the >> >>> DESTROY/REMOVE command. >> >> >> >> Hmm. How does this worked previously. I mean, do you see change of >> >> behaviour? I'm asking because I don't see how rules added only to HW >> >> could be removed, driver should care of it. Or are you talking about >> >> rules added to both SW and HW? >> > >> >These are rules added to both SW and HW. Previously all cls_* had >> >ndo_setup_tc calls based on the offload capability. >> > >> >commit 8d26d5636d "net: sched: avoid ndo_setup_tc calls for >> >TC_SETUP_CLS*" removed this bit to work with the new block callback. Is >> >there something similar in the block callback flow while acting on the >> >tcf_proto destroy call initiated when the qdisc is cleared? >> >> 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?
