netdev - Re: [patch net-next 00/10] net: allow user specify TC filter HW stats type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 29 Feb 2020 20:56:02 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Edward Cree <ecree@...arflare.com>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, saeedm@...lanox.com, leon@...nel.org,
        michael.chan@...adcom.com, vishal@...lsio.com,
        jeffrey.t.kirsher@...el.com, idosch@...lanox.com,
        aelior@...vell.com, peppe.cavallaro@...com,
        alexandre.torgue@...com, xiyou.wangcong@...il.com,
        mlxsw@...lanox.com, Marian Pritsak <marianp@...lanox.com>
Subject: Re: [patch net-next 00/10] net: allow user specify TC filter HW
 stats type

On Sat, Feb 29, 2020 at 09:01:20AM +0100, Jiri Pirko wrote:
> Fri, Feb 28, 2020 at 08:59:09PM CET, pablo@...filter.org wrote:
> >Hi Pirko,
> >
> >On Tue, Feb 25, 2020 at 05:22:03PM +0100, Jiri Pirko wrote:
> >[...]
> >> Eh, that is not that simple. The existing users are used to the fact
> >> that the actions are providing counters by themselves. Having and
> >> explicit counter action like this would break that expectation.
> >> Also, I think it should be up to the driver implementation. Some HW
> >> might only support stats per rule, not the actions. Driver should fit
> >> into the existing abstraction, I think it is fine.
> >
> >Something like the sketch patch that I'm attaching?
> 
> But why? Actions are separate entities, with separate counters. The
> driver is either able to offload that or not. Up to the driver to
> abstract this out.

You can add one counter for each action through FLOW_ACTION_COUNTER.
Then, one single tc action maps to two flow_actions, the action itself
and the counter action. Hence, the tc frontend only needs to append a
counter after the action.

Why this might be a problem from the driver side? From reading this
thread, my understanding is that:

1) Some drivers have the ability to attach to immediate/delayed
   counters.
2) The immediate counters might be a limited resource while delayed
   counters are abundant.
3) Some drivers have counters per-filter, not per-action. In that
   case, for each counter action in the rule, the driver might decide
   to make all counter actions refer to the per-filter counter.

Thank you!