Thu, Oct 26, 2017 at 10:24:31PM CEST, amritha.namb...@intel.com wrote: >On 10/25/2017 5:15 AM, Jiri Pirko wrote: >> Tue, Oct 24, 2017 at 06:01:34PM CEST, alexander.du...@gmail.com wrote: >> >> [...] >> >>> 1. To offload filter into HW, the hw-tc-offload feature flag has >>> to be turned on before creating the ingress qdisc. >>> >>> Previously, this could also be turned on after the qdisc was created >>> and the filters could still be offloaded. Looks like this is because, >>> previously the offload flag was checked as a part of filter >>> integration in the classifier, and now it is checked as part of qdisc >>> creation (ingress_init). So, if no offload capability is advertised at >>> ingress qdisc creation time then hardware will not be asked to offload >>> filters later if the flag is enabled. >> >> I have patchset that fixes this in my queue now. Will do some smoke >> testing and send later today. >> >> >>> >>> 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.
