netdev - Re: [RFC PATCH net-next 2/3] flow_offload: restore ability to collect separate stats per action

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:   Wed, 8 May 2019 10:02:21 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Edward Cree <ecree@...arflare.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Or Gerlitz <gerlitz.or@...il.com>
Subject: Re: [RFC PATCH net-next 2/3] flow_offload: restore ability to collect
 separate stats per action

On 2019-05-07 8:27 a.m., Edward Cree wrote:
> On 06/05/2019 13:41, Jamal Hadi Salim wrote:
>> On 2019-05-04 2:27 a.m., Jakub Kicinski wrote:
>>> On Fri, 3 May 2019 16:06:55 +0100, Edward Cree wrote:

[..]


> I don't know much of anything about RTM_GETACTION, but it doesn't appear
>   to be part of the current "tc offload" world, which AIUI is very much
>   centred around cls_flower.  I'm just trying to make counters in
>   cls_flower offload do 'the right thing' (whatever that may be), anything
>   else is out of scope.
> 

The lazy thing most people have done is essentially assume that
there is a stat per filter rule. From tc semantics that is an implicit
"pipe" action (which then carries stats).
And most times they implement a single action per match. I wouldnt call
it the 'the right thing'...

>> Most H/W i have seen has a global indexed stats table which is
>> shared by different action types (droppers, accept, mirror etc).
>> The specific actions may also have their own tables which also
>> then refer to the 32 bit index used in the stats table[1].
>> So for this to work well, the action will need at minimal to have
>> two indices one that is used in hardware stats table
>> and another that is kernel mapped to identify the attributes. Of
>> course we'll need to have a skip_sw flag etc.
> I'm not sure I'm parsing this correctly, but are you saying that the
>   index namespace is per-action type?  I.e. a mirred and a drop action
>   could have the same index yet expect to have separate counters?  My
>   approach here has assumed that in such a case they would share their
>   counters.

Yes, the index at tc semantics level is per-action type.
So "mirred index 1" and "drop index 1" are not the same stats counter.
Filters on the other hand can share per-action type stats by virtue of
sharing the same index per-action. e.g

flower match foo action drop index 1
flower match bar action drop index 1

will share the same stats.

cheers,
jamal