[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231207152409.v5nhbgn4pwdqunzw@skbuf>
Date: Thu, 7 Dec 2023 17:24:09 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Roger Quadros <rogerq@...nel.org>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, s-vadapalli@...com, r-gunasekaran@...com,
vigneshr@...com, srk@...com, horms@...nel.org, p-varis@...com,
netdev@...r.kernel.org
Subject: Re: [PATCH v7 net-next 6/8] net: ethernet: ti: am65-cpsw-qos: Add
Frame Preemption MAC Merge support
On Fri, Dec 01, 2023 at 03:58:00PM +0200, Roger Quadros wrote:
> - now passes all ethtool_mm.sh kselftests (patch 8 required)
There's another problem with your patch set, leading to the
traffic_test() selftest passing with the "emac" and "pmac" argument when
it shouldn't.
Drivers which implement frame preemption are supposed to be prepared to
distinguish, in their ethtool get_eth_mac_stats() method, between
ETHTOOL_MAC_STATS_SRC_EMAC, ETHTOOL_MAC_STATS_SRC_PMAC and
ETHTOOL_MAC_STATS_SRC_AGGREGATE. You don't, so you report the same thing
everywhere, which is incorrect, and it also fools the selftest.
I would like you to figure out which source are your stats coming from,
reject everything else, and edit the selftest to do something sensible
for your hardware. If it's as I suspect and the reported counters are
eMAC+pMAC aggregates, then I guess the most sensible thing to do would
be to probe the device with an ethtool -S --src pmac at the beginning of
the test, see what it reports, and if we don't get pMAC counters from
it, fall back to aggregate ones during calls to traffic_test().
Powered by blists - more mailing lists