Wed, Oct 25, 2017 at 03:29:27PM CEST, ogerl...@mellanox.com wrote: >On 10/25/2017 3:15 PM, 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? > >Jiri, on a possibly related note, dealing with some other tc/flower problems
Unrelated. What you describe is a separate issue. >on net, I came across a situation where we fail in the driverto offload some >flow (return -EINVALtowards the stack), and we immediately get a call from >the stack to delete this flow (f->cookie) > >this is the cookie and thereturn value > >mlx5e_configure_flower f->cookie c50e8c80 err -22 > >and then we getthis cookie for deletion where we fail again, b/c the flow is >not offloaded > >mlx5e_delete_flower f->cookie c50e8c80 Yes, that is intentional. The thing is, there might be multiple block callbacks registered and to be called. If there is a fail with one, we need to cleanup all. So in your case you have 1 cb registered, that means that in case of an error during insertion, you will get cb called to remove. Driver has to take care of that. I was checking that and was under impression that mlx5 deals with that.
