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? > > Thanks! >
