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]

Message-ID: <b6c5f811-2313-14a0-75c4-96d29196e7e6@solarflare.com>
Date:   Mon, 24 Feb 2020 11:38:20 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
CC:     <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>, <jhs@...atatu.com>,
        <xiyou.wangcong@...il.com>, <pablo@...filter.org>,
        <mlxsw@...lanox.com>
Subject: Re: [patch net-next 00/10] net: allow user specify TC filter HW stats
 type

On 22/02/2020 06:38, Jiri Pirko wrote:
> Fri, Feb 21, 2020 at 07:22:00PM CET, kuba@...nel.org wrote:
>> Hmm, but the statistics are on actions, it feels a little bit like we
>> are perpetuating the mistake of counting on filters here.
> You are right, the stats in tc are per-action. However, in both mlxsw
> and mlx5, the stats are per-filter. What hw_stats does is that it
> basically allows the user to set the type for all the actions in the
> filter at once.
>
> Could you imagine a usecase that would use different HW stats type for
> different actions in one action-chain?
Potentially a user could only want stats on one action and disable them
 on another.  For instance, if their action chain does delivery to the
 'customer' and also mirrors the packets for monitoring, they might only
 want stats on the first delivery (e.g. for billing) and not want to
 waste a counter on the mirror.

> Plus, if the fine grained setup is ever needed, the hw_stats could be in
> future easilyt extended to be specified per-action too overriding
> the per-filter setup only for specific action. What do you think?
I think this is improper; the stats type should be defined per-action in
 the uapi, even if userland initially only has UI to set it across the
 entire filter.  (I imagine `tc action` would grow the corresponding UI
 pretty quickly.)  Then on the driver side, you must determine whether
 your hardware can support the user's request, and if not, return an
 appropriate error code.

Let's try not to encourage people (users, future HW & driver developers)
 to keep thinking of stats as per-filter entities.

-ed