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]

Date:   Wed, 24 Apr 2019 16:11:39 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: TC stats / hw offload question

On Wed, Apr 24, 2019 at 03:05:05PM +0100, Edward Cree wrote:
> On 06/02/2019 02:20, Jamal Hadi Salim wrote:
> > The classifiers dont mod the packets. The actions do. And they
> > maintain stats on the size on "entry" i.e pre-edit.
> > Each action keeps its own counters. If you did something like:
> >
> > 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.
> > the "vlan action" would record x bytes.
> > the "redirect" would record size x+vlaninfo bytes
> > the egress of eth0 would  recorr x+vlaninfo bytes
> So, I had this working for a while, by calling tcf_action_stats_update()
>  directly on the correct element of tc->exts->actions[], instead of using
>  tcf_exts_stats_update().  And this was fine, until I tried to port my
>  code to the 5.1 kernel, with Pablo's flow action infrastructure.  On that
>  it's not possible, because there is only flow_stats_update(), which takes
>  a single bytes value for _all_ the actions in the rule.

Then, we need to extend the API to allow to update counters per
action, no driver in the tree has been supporting this so far.  May I
have a look at your driver code to infer what we might need?

Thanks.