netdev - RE: [PATCH v6 net-next 0/8] net: dsa: felix: psfp support on vsc9959

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]

Message-ID: <DB8PR04MB5785560CD2387A9D4FF9E259F0939@DB8PR04MB5785.eurprd04.prod.outlook.com>
Date:   Wed, 10 Nov 2021 10:32:32 +0000
From:   Xiaoliang Yang <xiaoliang.yang_1@....com>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
        "joergen.andreasen@...rochip.com" <joergen.andreasen@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        Po Liu <po.liu@....com>, Leo Li <leoyang.li@....com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "horatiu.vultur@...rochip.com" <horatiu.vultur@...rochip.com>
Subject: RE: [PATCH v6 net-next 0/8] net: dsa: felix: psfp support on vsc9959

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