Hi Vladimir,

On Oct 06, 2021 at 20:12:27 +0300, Vladimir Oltean wrote:

I'm very sorry for being late.
I wrote this selftest for the ingress time gating portion of Xiaoliang's work:

cat tools/testing/selftests/drivers/net/ocelot/psfp.sh
-----------------------------[ cut here ]----------------------------- #!/bin/bash #
SPDX-License-Identifier: GPL-2.0 # Copyright 2021 NXP

WAIT_TIME=1
NUM_NETIFS=4
lib_dir=$(dirname $0)/../../../net/forwarding source $lib_dir/tc_common.sh
source $lib_dir/lib.sh

...
Skip
...

-----------------------------[ cut here ]-----------------------------

and both tests pass with OK, but here are some parts of my log:


Expected filter to match on 0 packets but matched on 2 instead
                                          ~~~~~~~~~~~~~~~~~~~~
                                          I put "psfp_filter_check 0" at
the end of "setup_prepare",
                                          during a time where it is
guaranteed that no test packet belonging
                                          to the TSN stream has been
sent, yet the hardware seems to
                                          spuriously increment this
counter. This makes it very difficult
                                          to actually assess what's
going on by looking at counters.
                                          If you look at the comments,
the SFID counters increment
                                          spuriously even if I delete the
MAC table entry.

Hardware filter reports 0 drops
OK
[  275.429138] mscc_felix 0000:00:00.5: vsc9959_psfp_stats_get: pkts 1000
drops 0 sfid 0 match 1000 not_pass_gate 0 not_pass_sdu 0 red 0 Expected
filter to match on 1000 packets but matched on 1002 instead Hardware filter
reports 0 drops Accepted connection from 127.0.0.1 Accepted connection
from 127.0.0.1 OK [  288.091715] mscc_felix 0000:00:00.5:
vsc9959_psfp_stats_get: pkts 1000 drops 1000 sfid 0 match 1000
not_pass_gate 1000 not_pass_sdu 0 red 0

The hardware count also increased in my test. This happens occasionally when
first plug in the internet cable.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the driver sums these up and puts them

in stats->drops Expected filter to match on 2000 packets but matched on 2002
instead Hardware filter reports 0 drops ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
however "tc -s filter show ..." shows 0 drops, so the information is lost
somewhere along the way (the "packets" counter is correct though).

This is because stats.drops has not transmit to flow_stats_update() in ocelot_flower.c:
	flow_stats_update(&f->stats, 0x0, stats.pkts, 0, 0x0,
                          FLOW_ACTION_HW_STATS_IMMEDIATE);
I can update this though the stats.drops is not be used for other VCAPs rules.

It's very hard to have an opinion considering the fact that the hardware
doesn't behave according to my understanding. One of us must be wrong :)

Thanks,
Xiaoliang