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 for Android: free password hash cracker in your pocket

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

Message-ID: <4cb765dd-453f-3139-bce6-6e0b31167aec@mojatatu.com>
Date:   Tue, 5 Feb 2019 21:20:29 -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>
Subject: Re: TC stats / hw offload question

On 2019-02-05 2:41 p.m., Edward Cree wrote:
> Regarding TC_CLSFLOWER_STATS, when a filter rule modifies the length of
>   the packet, e.g. by adding a VLAN or encap header, should the bytes
>   counter count the length of the packet _before_ edits (i.e. as seen by
>   the match), or the length after edits?  

Classifier stats - when they exist - should be on
"classified" packets. i.e before edits.
Edits are typically done by actions. And even then we dont
have counters which indicate the post edit resizing.

> If the latter, what is the
>   correct behaviour when (say) a packet is mirrored as-is but also
>   redirected with encapsulation?

It is that ambiguity that make it hard to maintain a single
counter for post-edit size. packet and byte counts are on
"entry".

> The fact that the stats live in the struct tc_action suggests a per-
>   action connection that would imply post-edit length,

The classifiers dont mod the packets. The actions do. And they
maintain stats on the size on "entry" i.e pre-edit.

> but then in
>   tcf_exts_dump_stats() we only look at the first action, which seems to
>   imply we really want the pre-edit length.
> I can't find any kind of doc or spec defining what behaviour is required.
> 

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

cheers,
jamal

> -Ed
>