Re: TC stats / hw offload question

Jamal Hadi Salim
2019-02-06T02:20:34Z

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
>