netdev - Re: [PATCH net-next 2/6] sfc: implement basic per-queue stats

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: <d521cec8-a112-48b1-8368-f7ff406502fb@intel.com>
Date: Wed, 28 Aug 2024 15:20:53 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: <edward.cree@....com>, <linux-net-drivers@....com>, <davem@...emloft.net>,
	<kuba@...nel.org>, <edumazet@...gle.com>, <pabeni@...hat.com>
CC: Edward Cree <ecree.xilinx@...il.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/6] sfc: implement basic per-queue stats



On 8/28/2024 6:45 AM, edward.cree@....com wrote:
> From: Edward Cree <ecree.xilinx@...il.com>
> 
> Just RX and TX packet counts for now.  We do not have per-queue
>  byte counts, which causes us to fail stats.pkt_byte_sum selftest
>  with "Drivers should always report basic keys" error.

Seems like the self tests here should be fixed for this?

> Per-queue counts are since the last time the queue was inited
>  (typically by efx_start_datapath(), on ifup or reconfiguration);
>  device-wide total (efx_get_base_stats()) is since driver probe.
>  This is not the same lifetime as rtnl_link_stats64, which uses
>  firmware stats which count since FW (re)booted; this can cause a
>  "Qstats are lower" or "RTNL stats are lower" failure in
>  stats.pkt_byte_sum selftest.

Could we have software somehow manage this so that the actual reported
stats correctly survive the lifetime of the FW instead of surviving only
from the queue initialization?

> Move the increment of rx_queue->rx_packets to match the semantics
>  specified for netdev per-queue stats, i.e. just before handing
>  the packet to XDP (if present) or the netstack (through GRO).
>  This will affect the existing ethtool -S output which also
>  reports these counters.
> 
Seems reasonable.