From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2FC18C87FCB for ; Wed, 30 Jul 2025 11:33:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D0E9C40C88; Wed, 30 Jul 2025 11:32:59 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id LGQj7RVkTvdu; Wed, 30 Jul 2025 11:32:59 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4097640C10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1753875179; bh=uHW3kJohF557YGobfQDpyiyx5O/H1BpxwxCIIzE1A1k=; h=Date:To:Cc:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=soKjtr+xULpBICZJC7A1qlp/rF94wLbdo0e4Fgdg7wj9YW5PLBf6NCurLg+hsKZUC gEhG2vELm7hkG2jd10j8WQsmxEwyHmQQK/wIfVBT4hdAAQ10SL/XI1vWL3rXgHJrju zw7kaC7d/MIaB/krfTSGWtc9o9NHMtETLq2ZNnuOnTustjbXbJ8okachroSmabFCNb aL89HcKzKxJ10oWHIJtwoot3v+nzwZv8WO2QWgOgyI+1RzGPIw88aPwjf3hFrML1KQ kQP/YyQAnCslKJm50LWDMOrK18liPGMresp5t61Ccq1aqZo68cpBEq/jcdNtmn/x6X QEvhz/2bhZbTA== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp4.osuosl.org (Postfix) with ESMTP id 4097640C10; Wed, 30 Jul 2025 11:32:59 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists1.osuosl.org (Postfix) with ESMTP id E35E813D for ; Wed, 30 Jul 2025 11:32:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C9C4040C1D for ; Wed, 30 Jul 2025 11:32:56 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id 3-70bHRIEqnQ for ; Wed, 30 Jul 2025 11:32:56 +0000 (UTC) X-Greylist: delayed 62687 seconds by postgrey-1.37 at util1-new.osuosl.org; Wed, 30 Jul 2025 11:32:55 UTC DMARC-Filter: OpenDMARC Filter v1.4.2 smtp4.osuosl.org B4C0640C0E DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B4C0640C0E Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=95.215.58.173; helo=out-173.mta1.migadu.com; envelope-from=vadim.fedorenko@linux.dev; receiver= Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by smtp4.osuosl.org (Postfix) with ESMTPS id B4C0640C0E for ; Wed, 30 Jul 2025 11:32:55 +0000 (UTC) Message-ID: <8b22e9d3-e4d2-4726-9622-28881b2cd406@linux.dev> Date: Wed, 30 Jul 2025 12:32:43 +0100 MIME-Version: 1.0 To: Gal Pressman , Andrew Lunn , Michael Chan , Pavan Chebbi , Tariq Toukan , intel-wired-lan@lists.osuosl.org, Donald Hunter , Jakub Kicinski Cc: Paolo Abeni , Simon Horman , netdev@vger.kernel.org References: <20250729102354.771859-1-vadfed@meta.com> <041f79a2-5f96-4427-b0e2-6a159fbec84a@nvidia.com> <1129bf26-273e-4685-a0b8-ed8b0e4050f3@linux.dev> <3e84a20e-87ea-413c-9e9d-950605a55bf6@nvidia.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: <3e84a20e-87ea-413c-9e9d-950605a55bf6@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1753875171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uHW3kJohF557YGobfQDpyiyx5O/H1BpxwxCIIzE1A1k=; b=bukVWX11iXapIW2wm/IWiowp//jiNbLbLJLMmIY9LeEDVHA1rcLhzj4rcYxfFIO1n2CefM vgUA28+Glk97rQsmJSHzdjLQq/Sa/4vUonVYXMUm27DYo6za5u5zR6RydbMBDLouMeuebL vxEv4qDovEnshA2Q1SJmunSYt9JQcto= X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dmarc=pass (p=none dis=none) header.from=linux.dev X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=bukVWX11 Subject: Re: [Intel-wired-lan] [RFC PATCH] ethtool: add FEC bins histogramm report X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On 30/07/2025 11:42, Gal Pressman wrote: > On 30/07/2025 12:29, Vadim Fedorenko wrote: >> 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. > > This is just adding unnecessary complexity to the drivers, trying to > figure out the right lifetime for this array. > It will be much simpler if the core passes an array for the drivers to > fill. That way both static and dynamic ranges would work the same. There is no need to pass huge pre-allocated array for drivers which doesn't have support for the histogram. The core doesn't have this info about the driver. And again - there is no need to refill ranges array every time as it will not change. I believe it's pure driver area of knowledge and responsibility. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2C1415E96 for ; Wed, 30 Jul 2025 11:32:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753875175; cv=none; b=MOqnncQpvEUsIQWppNFQTk0Sgg0x9us8ptRT4y1/7rZmewpPR9+ltp7JPoyAxGxsuElL+cIcIUbAsUNrwPnvCIiV6vOwGIMyBuT7k0YmaocYcU5TxXqGqXhLnOTxbz5pTd+AklD4933faRuwcxlkKzRxEOPnohF5YxwMEls99CQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753875175; c=relaxed/simple; bh=nsC0IZElzNqZiVyzWCZWUL4M9nsnN0tzZgv/WMalr04=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EfG1QdGQbDZYneJgogssoz2Kf7cO02KKHJsZX9v1X/l7ktkaaEGcfeTJ7hICd7xXQ7Y6XKnii4ABNZZ+fAORRsggLXF8/84qiQi+3Tg1aayC2Iq/iS/qQH4gbbi3TCd/f8WcHh0nqPCobMIjtE+uduJLQ1lNm8wleBDnHnogizU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=bukVWX11; arc=none smtp.client-ip=95.215.58.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="bukVWX11" Message-ID: <8b22e9d3-e4d2-4726-9622-28881b2cd406@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1753875171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uHW3kJohF557YGobfQDpyiyx5O/H1BpxwxCIIzE1A1k=; b=bukVWX11iXapIW2wm/IWiowp//jiNbLbLJLMmIY9LeEDVHA1rcLhzj4rcYxfFIO1n2CefM vgUA28+Glk97rQsmJSHzdjLQq/Sa/4vUonVYXMUm27DYo6za5u5zR6RydbMBDLouMeuebL vxEv4qDovEnshA2Q1SJmunSYt9JQcto= Date: Wed, 30 Jul 2025 12:32:43 +0100 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH] ethtool: add FEC bins histogramm report To: Gal Pressman , Andrew Lunn , Michael Chan , Pavan Chebbi , Tariq Toukan , intel-wired-lan@lists.osuosl.org, Donald Hunter , Jakub Kicinski Cc: Paolo Abeni , Simon Horman , netdev@vger.kernel.org References: <20250729102354.771859-1-vadfed@meta.com> <041f79a2-5f96-4427-b0e2-6a159fbec84a@nvidia.com> <1129bf26-273e-4685-a0b8-ed8b0e4050f3@linux.dev> <3e84a20e-87ea-413c-9e9d-950605a55bf6@nvidia.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: <3e84a20e-87ea-413c-9e9d-950605a55bf6@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 30/07/2025 11:42, Gal Pressman wrote: > On 30/07/2025 12:29, Vadim Fedorenko wrote: >> 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. > > This is just adding unnecessary complexity to the drivers, trying to > figure out the right lifetime for this array. > It will be much simpler if the core passes an array for the drivers to > fill. That way both static and dynamic ranges would work the same. There is no need to pass huge pre-allocated array for drivers which doesn't have support for the histogram. The core doesn't have this info about the driver. And again - there is no need to refill ranges array every time as it will not change. I believe it's pure driver area of knowledge and responsibility.