public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Gal Pressman <gal@nvidia.com>, Andrew Lunn <andrew@lunn.ch>,
	Michael Chan <michael.chan@broadcom.com>,
	Pavan Chebbi <pavan.chebbi@broadcom.com>,
	Tariq Toukan <tariqt@nvidia.com>,
	intel-wired-lan@lists.osuosl.org,
	Donald Hunter <donald.hunter@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [RFC PATCH] ethtool: add FEC bins histogramm report
Date: Wed, 30 Jul 2025 10:29:36 +0100	[thread overview]
Message-ID: <1129bf26-273e-4685-a0b8-ed8b0e4050f3@linux.dev> (raw)
In-Reply-To: <041f79a2-5f96-4427-b0e2-6a159fbec84a@nvidia.com>

On 30/07/2025 06:54, Gal Pressman wrote:
> On 29/07/2025 13:23, Vadim Fedorenko wrote:
>> diff --git a/drivers/net/netdevsim/ethtool.c b/drivers/net/netdevsim/ethtool.c
>> index f631d90c428ac..7257de9ea2f44 100644
>> --- a/drivers/net/netdevsim/ethtool.c
>> +++ b/drivers/net/netdevsim/ethtool.c
>> @@ -164,12 +164,25 @@ nsim_set_fecparam(struct net_device *dev, struct ethtool_fecparam *fecparam)
>>   	ns->ethtool.fec.active_fec = 1 << (fls(fec) - 1);
>>   	return 0;
>>   }
>> +static const struct ethtool_fec_hist_range netdevsim_fec_ranges[] = {
>> +	{  0,  0},
>> +	{  1,  3},
>> +	{  4,  7},
>> +	{ -1, -1}
>> +};
> 
> The driver-facing API works nicely when the ranges are allocated as
> static arrays, but I expect most drivers will need to allocate it
> dynamically as the ranges will be queried from the device.
> In that case, we need to define who is responsible of freeing the ranges
> array.

Well, the ranges will not change during link operation, unless the type
of FEC is changed. You may either have static array of FEC ranges per
supported FEC types. Or query it on link-up event and reuse it on every
call for FEC stats. In this case it's pure driver's responsibility to
manage memory allocations. There is definitely no need to re-query
ranges on every single call for stats.

> 
>>   
>>   static void
>> -nsim_get_fec_stats(struct net_device *dev, struct ethtool_fec_stats *fec_stats)
>> +nsim_get_fec_stats(struct net_device *dev, struct ethtool_fec_stats *fec_stats,
>> +		   const struct ethtool_fec_hist_range **ranges)
>>   {
>> +	*ranges = netdevsim_fec_ranges;
>> +
>>   	fec_stats->corrected_blocks.total = 123;
>>   	fec_stats->uncorrectable_blocks.total = 4;
>> +
>> +	fec_stats->hist[0] = 345;
>> +	fec_stats->hist[1] = 12;
>> +	fec_stats->hist[2] = 2;
>>   }
>>   
>>   static int nsim_get_ts_info(struct net_device *dev,
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index de5bd76a400ca..9421a5e31af21 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -492,6 +492,17 @@ struct ethtool_pause_stats {
>>   };
>>   
>>   #define ETHTOOL_MAX_LANES	8
>> +#define ETHTOOL_FEC_HIST_MAX	18
> 
> I suspect we might need to increase this value in the future, so I like
> the fact that it's not hardcoded anywhere in the uapi.

Yep, that's the plan

  reply	other threads:[~2025-07-30  9:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-29 10:23 [RFC PATCH] ethtool: add FEC bins histogramm report Vadim Fedorenko
2025-07-29 13:48 ` Andrew Lunn
2025-07-29 16:01   ` Vadim Fedorenko
2025-07-29 16:17     ` Andrew Lunn
2025-07-29 16:36       ` Vadim Fedorenko
2025-07-29 17:31         ` Andrew Lunn
2025-07-29 18:07           ` Vadim Fedorenko
2025-07-30  1:51             ` Jakub Kicinski
2025-07-30  5:39               ` Gal Pressman
2025-07-30 12:59                 ` Andrew Lunn
2025-07-30 13:54                   ` Gal Pressman
2025-07-30  9:18               ` Vadim Fedorenko
2025-07-30 13:44                 ` Jakub Kicinski
2025-07-30 14:39                   ` Vadim Fedorenko
2025-07-30  1:45 ` Jakub Kicinski
2025-07-30  9:22   ` Vadim Fedorenko
2025-07-30 13:45     ` Jakub Kicinski
2025-07-30  1:48 ` Jakub Kicinski
2025-07-30  5:54 ` Gal Pressman
2025-07-30  9:29   ` Vadim Fedorenko [this message]
2025-07-30 10:42     ` Gal Pressman
2025-07-30 11:32       ` Vadim Fedorenko
2025-07-30 13:47         ` Gal Pressman
2025-07-30 14:15           ` Andrew Lunn
2025-07-30 12:08 ` Carolina Jubran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1129bf26-273e-4685-a0b8-ed8b0e4050f3@linux.dev \
    --to=vadim.fedorenko@linux.dev \
    --cc=andrew@lunn.ch \
    --cc=donald.hunter@gmail.com \
    --cc=gal@nvidia.com \
    --cc=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox