netdev - Re: TC stats / hw offload question

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: <561205a6-101b-c86b-e77d-6ebdcf31a56d@mojatatu.com>
Date:   Sat, 9 Feb 2019 12:39:15 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Edward Cree <ecree@...arflare.com>, netdev <netdev@...r.kernel.org>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        PJ Waskiewicz <pjwaskiewicz@...il.com>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: Re: TC stats / hw offload question

On 2019-02-08 5:26 a.m., Edward Cree wrote:
> On 06/02/19 02:20, Jamal Hadi Salim wrote:

>> tc match using flower blah \
>> action vlan push tag ... \
>> action redirect to egress of eth0
>>
>> And you submited a packet of size x bytes,
>> then the "match" would record x bytes.
 >
> Sorry, where would it record that?

Sorry - that was hypothetical on my part. We dont
record the bytes in the classifier. We do (on some
classifiers) record hit counts, so we can see how many
times a lookup on a specific filter happened and how
many times that lookup resulted in a match.
See u32 (or a few others Cong has been updating
recently).

>  I can't find any stats counters on
>   the "match" either in the software path or the offload API.

Hasnt been necessary thus far.
Is your end goal to match and count?
Most hardware has stats/counters as a separate table.
Assuming yours does as well, then if all you want was
to just match and accept, then you would add a filter
with an accept/ok. i.e something along the lines of:

tc match using flower blah \
action ok index 12345

The "action index" field can be used to map to a counter
table index in hardware. Note if you dont explicitly
specify the index, the kernel (and in this case h/w)
issues one for you.

>> the "vlan action" would record x bytes.
>> the "redirect" would record size x+vlaninfo bytes
>> the egress of eth0 would  recorr x+vlaninfo bytes
> Am I right in thinking that offloaded counters don't do that?  As far
>   as I can tell, the drivers with flower offload all use
>   tcf_exts_stats_update() which takes a single 'bytes' count and adds
>   it to all the actions.  (Presumably this is pre-edit length.)

On the pre/post edit, perhaps some of the hardware
owners could chime in +Ccing a few.

To the tcf_exts_stats_update():
Note, most people interested in h/w offload will choose to skip
sw (explicitly defined when you add  a rule).
The update synchronizes the hardware stats/counters
to the kernel - so when you dump the policies in such a setup
you are seeing what is reflected in hardware.

cheers,
jamal

PS: I have to say just keeping one counter is at times
insufficient. Example, the policer records how many bytes
were seen, not how many bytes were allowed through.
For tunnels, it is easy to compute post-edit size because
you can easily compute later the added/removed bytes.