On Wed, Oct 11, 2017 at 12:47 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 12:16 AM, Jiri Pirko <j...@resnulli.us> wrote: >> Tue, Oct 10, 2017 at 10:08:23PM CEST, gerlitz...@gmail.com wrote: >>>On Tue, Oct 10, 2017 at 10:30 AM, Jiri Pirko <j...@resnulli.us> wrote: >>>> The only user of cls_flower->egress_dev is mlx5. >>> >>>but nfp supports decap action offload too and from the flower code >>>stand point, I guess they are both the same, right? how does it work there?
>> Apparently they don't use cls_flower->egress_dev. > John, can you elaborate on that, how do you manage to get away from > that practice? Looking on this a little more, it's clearly obvious that both fl_hw_update_stats and fl_hw_destroy_filter never set egress_dev on the local variable which is set down to the driver through the ndo. For cases such as decap flow set on virtual SW tunnel device where f->hw_dev is the egress port, mlx5 fails to internally locate the driver rule object and we return -EINVAL on both cases and hence deletion or stats will not take place. I verified that in black box manner for both cases of deletion (the specific filer or the whole ingress qdisc) and for the stats. We have per ingress port rules table on the driver and maybe nfp doesn't and hence why they didn't fell on that, not sure, I copied the folks here. Commit a6e1693129 "net/sched: cls_flower: Set the filter Hardware device for all use-cases" tries to fix something and does mention the stats and destroy cases, but I don't see how it helps for that :( I will keep looking next week (starting holiday here now) and try to get a fix for net and stable. Or.
