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
