[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ed2ba1e-b87f-4738-9d72-da7c5a7180e2@lunn.ch>
Date: Sun, 17 Nov 2024 21:19:00 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, alexanderduyck@...com,
Sanman Pradhan <sanman.p211993@...il.com>
Subject: Re: [PATCH net-next 4/5] eth: fbnic: add PCIe hardware statistics
> +/* PUL User Registers*/
> +#define FBNIC_PUL_USER_OB_RD_TLP_CNT_31_0 \
> + 0x3106e /* 0xc41b8 */
Is there a comment somewhere which explains what these comments mean?
Otherwise they appear to be useless magic numbers.
> +static void fbnic_hw_stat_rst64(struct fbnic_dev *fbd, u32 reg, s32 offset,
> + struct fbnic_stat_counter *stat)
> +{
> + /* Record initial counter values and compute deltas from there to ensure
> + * stats start at 0 after reboot/reset. This avoids exposing absolute
> + * hardware counter values to userspace.
> + */
> + stat->u.old_reg_value_64 = fbnic_stat_rd64(fbd, reg, offset);
I don't know how you use these stats, but now they are in debugfs, do
they actually need to be 0 after reboot/reset? For most debugging
performance issues with statistics, i want to know how much a counter
goes up per second, so userspace will be reading the values twice with
a sleep, and doing a subtractions anyway. So why not make the kernel
code simpler?
Andrew
Powered by blists - more mailing lists